Gnome dropping Bugzilla

classic Classic list List threaded Threaded
15 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Gnome dropping Bugzilla

John Ralls-2
As I think everyone knows, we use bugzilla.gnome.org <http://bugzilla.gnome.org/> for bug and enhancement tracking.

There's a new banner on every BZ page saying that Gnome plans to drop Bugzilla and the CGit repository browser, replacing them with Gitlab.

That isn't going to work for us. I don't think it's going to work for Gnome, either, because a bug tracker that can't do word searches isn't capable of managing thousands of open bugs (https://docs.gitlab.com/ee/user/search/index.html <https://docs.gitlab.com/ee/user/search/index.html>), but that's not our problem. Our problem is that with our repository not at git.gnome.org <http://git.gnome.org/> there won't be a GnuCash project in GitLab and so there won't be a bug tracker. We'll need to get a new one.

Since we do mirror our repos to Github it is a viable option and it does at least have better search facilities (or at least they're better documented) that Gitlab, see https://help.github.com/articles/searching-issues-and-pull-requests/ <https://help.github.com/articles/searching-issues-and-pull-requests/>. It lacks many other features of BZ: All categorization and status tracking is by "labels" and they have no inherent hierarchy or organization.

So I think we're going to need our own bugtracker.

BZ is Free and it should be fairly simple to get the Gnome bug team to ship us a dump of our part of the database and set up a redirect once we have our instance up and running. The web display on whatever it is that GNU uses (e.g. https://savannah.gnu.org/bugs/?group=guile <https://savannah.gnu.org/bugs/?group=guile>) but I dislike that it is operated entirely by email. Mantis is popular but is managed by a bug list. It's filterable to a fare-thee-well but lacks controlled vocabularies on many of its fields so managing a large number of open bugs is a PITA. RT (used by perl's CPAN) is also completely email driven. Trac is a little less rudimentary than Github--it at least has categories and status fields, but I don't believe it's capable of managing thousands of bugs. SourceForge's built in tracker is on the same level as Github's with less capable search.

There's a sort of conceptual timeline on the DevelopmentInfrastructure page but nothing concrete. I'd guess we have at least several months and perhaps as long as a year to have a replacement up and running.

Regards,
John Ralls
_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Gnome dropping Bugzilla

Derek Atkins-3
I have never set up a Bugzilla system, but it's already packaged so it
should be as simple as "dnf install bugzilla" on code and then configuring
it.

code already runs a mysql database for the wiki, so adding another for BZ
shouldn't be a problem.

I dont know how hard it would be to get a DB dump of our stuff in order to
migrate it.

Obviously every URL pointing at gnome's bugzilla would break, including
those in our sources and documentation.

-derek

On Mon, July 31, 2017 3:56 pm, John Ralls wrote:

> As I think everyone knows, we use bugzilla.gnome.org
> <http://bugzilla.gnome.org/> for bug and enhancement tracking.
>
> There's a new banner on every BZ page saying that Gnome plans to drop
> Bugzilla and the CGit repository browser, replacing them with Gitlab.
>
> That isn't going to work for us. I don't think it's going to work for
> Gnome, either, because a bug tracker that can't do word searches isn't
> capable of managing thousands of open bugs
> (https://docs.gitlab.com/ee/user/search/index.html
> <https://docs.gitlab.com/ee/user/search/index.html>), but that's not our
> problem. Our problem is that with our repository not at git.gnome.org
> <http://git.gnome.org/> there won't be a GnuCash project in GitLab and so
> there won't be a bug tracker. We'll need to get a new one.
>
> Since we do mirror our repos to Github it is a viable option and it does
> at least have better search facilities (or at least they're better
> documented) that Gitlab, see
> https://help.github.com/articles/searching-issues-and-pull-requests/
> <https://help.github.com/articles/searching-issues-and-pull-requests/>. It
> lacks many other features of BZ: All categorization and status tracking is
> by "labels" and they have no inherent hierarchy or organization.
>
> So I think we're going to need our own bugtracker.
>
> BZ is Free and it should be fairly simple to get the Gnome bug team to
> ship us a dump of our part of the database and set up a redirect once we
> have our instance up and running. The web display on whatever it is that
> GNU uses (e.g. https://savannah.gnu.org/bugs/?group=guile
> <https://savannah.gnu.org/bugs/?group=guile>) but I dislike that it is
> operated entirely by email. Mantis is popular but is managed by a bug
> list. It's filterable to a fare-thee-well but lacks controlled
> vocabularies on many of its fields so managing a large number of open bugs
> is a PITA. RT (used by perl's CPAN) is also completely email driven. Trac
> is a little less rudimentary than Github--it at least has categories and
> status fields, but I don't believe it's capable of managing thousands of
> bugs. SourceForge's built in tracker is on the same level as Github's with
> less capable search.
>
> There's a sort of conceptual timeline on the DevelopmentInfrastructure
> page but nothing concrete. I'd guess we have at least several months and
> perhaps as long as a year to have a replacement up and running.
>
> Regards,
> John Ralls
> _______________________________________________
> gnucash-devel mailing list
> [hidden email]
> https://lists.gnucash.org/mailman/listinfo/gnucash-devel
>


--
       Derek Atkins                 617-623-3745
       [hidden email]             www.ihtfp.com
       Computer and Internet Security Consultant

_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Gnome dropping Bugzilla

Eric Theise
In reply to this post by John Ralls-2
I'm a fan of the IDEs produced by JetBrains (RubyMine, PyCharm, et al.) but
admit upfront that I have not worked with their tracking product, YouTrack.
Worth a look though? Free hosting for open source projects.

Bug and Issue Tracking overview
https://www.jetbrains.com/youtrack/features/issue_tracking.html

Searching for Issues video
https://www.youtube.com/watch?v=fzkKcG7KIhI&index=23&list=PLQ176FUIyIUbGE728KezWz1J15fHW0S_m

Import from Bugzilla
https://www.jetbrains.com/help/youtrack/incloud/7.0/Import-from-Bugzilla.html

Free Open Source licensing
https://www.jetbrains.com/buy/opensource/?product=youtrack

other Demos and Screencasts
https://www.youtube.com/playlist?list=PLQ176FUIyIUbGE728KezWz1J15fHW0S_m

Eric


On Mon, Jul 31, 2017 at 12:56 PM, John Ralls <[hidden email]> wrote:

> As I think everyone knows, we use bugzilla.gnome.org <
> http://bugzilla.gnome.org/> for bug and enhancement tracking.
>
> There's a new banner on every BZ page saying that Gnome plans to drop
> Bugzilla and the CGit repository browser, replacing them with Gitlab.
>
> That isn't going to work for us. I don't think it's going to work for
> Gnome, either, because a bug tracker that can't do word searches isn't
> capable of managing thousands of open bugs (https://docs.gitlab.com/ee/
> user/search/index.html <https://docs.gitlab.com/ee/user/search/index.html>),
> but that's not our problem. Our problem is that with our repository not at
> git.gnome.org <http://git.gnome.org/> there won't be a GnuCash project in
> GitLab and so there won't be a bug tracker. We'll need to get a new one.
>
> Since we do mirror our repos to Github it is a viable option and it does
> at least have better search facilities (or at least they're better
> documented) that Gitlab, see https://help.github.com/
> articles/searching-issues-and-pull-requests/ <https://help.github.com/
> articles/searching-issues-and-pull-requests/>. It lacks many other
> features of BZ: All categorization and status tracking is by "labels" and
> they have no inherent hierarchy or organization.
>
> So I think we're going to need our own bugtracker.
>
> BZ is Free and it should be fairly simple to get the Gnome bug team to
> ship us a dump of our part of the database and set up a redirect once we
> have our instance up and running. The web display on whatever it is that
> GNU uses (e.g. https://savannah.gnu.org/bugs/?group=guile <
> https://savannah.gnu.org/bugs/?group=guile>) but I dislike that it is
> operated entirely by email. Mantis is popular but is managed by a bug list.
> It's filterable to a fare-thee-well but lacks controlled vocabularies on
> many of its fields so managing a large number of open bugs is a PITA. RT
> (used by perl's CPAN) is also completely email driven. Trac is a little
> less rudimentary than Github--it at least has categories and status fields,
> but I don't believe it's capable of managing thousands of bugs.
> SourceForge's built in tracker is on the same level as Github's with less
> capable search.
>
> There's a sort of conceptual timeline on the DevelopmentInfrastructure
> page but nothing concrete. I'd guess we have at least several months and
> perhaps as long as a year to have a replacement up and running.
>
> Regards,
> John Ralls
> _______________________________________________
> gnucash-devel mailing list
> [hidden email]
> https://lists.gnucash.org/mailman/listinfo/gnucash-devel
>
_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Gnome dropping Bugzilla

Herbert Mühlburger
In reply to this post by John Ralls-2
What about using Jira?

--
Herbert Mühlburger

Email: [hidden email]
Web: https://blog.muehlburger.at

Am Mo, 31. Jul 2017, um 21:56, schrieb John Ralls:

> As I think everyone knows, we use bugzilla.gnome.org
> <http://bugzilla.gnome.org/> for bug and enhancement tracking.
>
> There's a new banner on every BZ page saying that Gnome plans to drop
> Bugzilla and the CGit repository browser, replacing them with Gitlab.
>
> That isn't going to work for us. I don't think it's going to work for
> Gnome, either, because a bug tracker that can't do word searches isn't
> capable of managing thousands of open bugs
> (https://docs.gitlab.com/ee/user/search/index.html
> <https://docs.gitlab.com/ee/user/search/index.html>), but that's not our
> problem. Our problem is that with our repository not at git.gnome.org
> <http://git.gnome.org/> there won't be a GnuCash project in GitLab and so
> there won't be a bug tracker. We'll need to get a new one.
>
> Since we do mirror our repos to Github it is a viable option and it does
> at least have better search facilities (or at least they're better
> documented) that Gitlab, see
> https://help.github.com/articles/searching-issues-and-pull-requests/
> <https://help.github.com/articles/searching-issues-and-pull-requests/>.
> It lacks many other features of BZ: All categorization and status
> tracking is by "labels" and they have no inherent hierarchy or
> organization.
>
> So I think we're going to need our own bugtracker.
>
> BZ is Free and it should be fairly simple to get the Gnome bug team to
> ship us a dump of our part of the database and set up a redirect once we
> have our instance up and running. The web display on whatever it is that
> GNU uses (e.g. https://savannah.gnu.org/bugs/?group=guile
> <https://savannah.gnu.org/bugs/?group=guile>) but I dislike that it is
> operated entirely by email. Mantis is popular but is managed by a bug
> list. It's filterable to a fare-thee-well but lacks controlled
> vocabularies on many of its fields so managing a large number of open
> bugs is a PITA. RT (used by perl's CPAN) is also completely email driven.
> Trac is a little less rudimentary than Github--it at least has categories
> and status fields, but I don't believe it's capable of managing thousands
> of bugs. SourceForge's built in tracker is on the same level as Github's
> with less capable search.
>
> There's a sort of conceptual timeline on the DevelopmentInfrastructure
> page but nothing concrete. I'd guess we have at least several months and
> perhaps as long as a year to have a replacement up and running.
>
> Regards,
> John Ralls
> _______________________________________________
> gnucash-devel mailing list
> [hidden email]
> https://lists.gnucash.org/mailman/listinfo/gnucash-devel
_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Gnome dropping Bugzilla

John Ralls
The problem with both YouTrack and Jira is that they're free for open source until they're not, and when they're not we're screwed. We've already had that experience with Uservoice, which was free when they rolled it out--and our account is grandfathered at least for now--but no new free accounts can be created.

Regards,
John Ralls

> On Aug 1, 2017, at 8:11 AM, Herbert Mühlburger <[hidden email]> wrote:
>
> What about using Jira?
>
> --
> Herbert Mühlburger
>
> Email: [hidden email]
> Web: https://blog.muehlburger.at
>
> Am Mo, 31. Jul 2017, um 21:56, schrieb John Ralls:
>> As I think everyone knows, we use bugzilla.gnome.org
>> <http://bugzilla.gnome.org/> for bug and enhancement tracking.
>>
>> There's a new banner on every BZ page saying that Gnome plans to drop
>> Bugzilla and the CGit repository browser, replacing them with Gitlab.
>>
>> That isn't going to work for us. I don't think it's going to work for
>> Gnome, either, because a bug tracker that can't do word searches isn't
>> capable of managing thousands of open bugs
>> (https://docs.gitlab.com/ee/user/search/index.html
>> <https://docs.gitlab.com/ee/user/search/index.html>), but that's not our
>> problem. Our problem is that with our repository not at git.gnome.org
>> <http://git.gnome.org/> there won't be a GnuCash project in GitLab and so
>> there won't be a bug tracker. We'll need to get a new one.
>>
>> Since we do mirror our repos to Github it is a viable option and it does
>> at least have better search facilities (or at least they're better
>> documented) that Gitlab, see
>> https://help.github.com/articles/searching-issues-and-pull-requests/
>> <https://help.github.com/articles/searching-issues-and-pull-requests/>.
>> It lacks many other features of BZ: All categorization and status
>> tracking is by "labels" and they have no inherent hierarchy or
>> organization.
>>
>> So I think we're going to need our own bugtracker.
>>
>> BZ is Free and it should be fairly simple to get the Gnome bug team to
>> ship us a dump of our part of the database and set up a redirect once we
>> have our instance up and running. The web display on whatever it is that
>> GNU uses (e.g. https://savannah.gnu.org/bugs/?group=guile
>> <https://savannah.gnu.org/bugs/?group=guile>) but I dislike that it is
>> operated entirely by email. Mantis is popular but is managed by a bug
>> list. It's filterable to a fare-thee-well but lacks controlled
>> vocabularies on many of its fields so managing a large number of open
>> bugs is a PITA. RT (used by perl's CPAN) is also completely email driven.
>> Trac is a little less rudimentary than Github--it at least has categories
>> and status fields, but I don't believe it's capable of managing thousands
>> of bugs. SourceForge's built in tracker is on the same level as Github's
>> with less capable search.
>>
>> There's a sort of conceptual timeline on the DevelopmentInfrastructure
>> page but nothing concrete. I'd guess we have at least several months and
>> perhaps as long as a year to have a replacement up and running.
>>
>> Regards,
>> John Ralls
>> _______________________________________________
>> gnucash-devel mailing list
>> [hidden email]
>> https://lists.gnucash.org/mailman/listinfo/gnucash-devel
> _______________________________________________
> gnucash-devel mailing list
> [hidden email]
> https://lists.gnucash.org/mailman/listinfo/gnucash-devel

_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Gnome dropping Bugzilla

John Ralls-2
In reply to this post by Herbert Mühlburger
The problem with both YouTrack and Jira is that they're free for open source until they're not, and when they're not we're screwed. We've already had that experience with Uservoice, which was free when they rolled it out--and our account is grandfathered at least for now--but no new free accounts can be created.

Regards,
John Ralls

> On Aug 1, 2017, at 8:11 AM, Herbert Mühlburger <[hidden email]> wrote:
>
> What about using Jira?
>
> --
> Herbert Mühlburger
>
> Email: [hidden email]
> Web: https://blog.muehlburger.at
>
> Am Mo, 31. Jul 2017, um 21:56, schrieb John Ralls:
>> As I think everyone knows, we use bugzilla.gnome.org
>> <http://bugzilla.gnome.org/> for bug and enhancement tracking.
>>
>> There's a new banner on every BZ page saying that Gnome plans to drop
>> Bugzilla and the CGit repository browser, replacing them with Gitlab.
>>
>> That isn't going to work for us. I don't think it's going to work for
>> Gnome, either, because a bug tracker that can't do word searches isn't
>> capable of managing thousands of open bugs
>> (https://docs.gitlab.com/ee/user/search/index.html
>> <https://docs.gitlab.com/ee/user/search/index.html>), but that's not our
>> problem. Our problem is that with our repository not at git.gnome.org
>> <http://git.gnome.org/> there won't be a GnuCash project in GitLab and so
>> there won't be a bug tracker. We'll need to get a new one.
>>
>> Since we do mirror our repos to Github it is a viable option and it does
>> at least have better search facilities (or at least they're better
>> documented) that Gitlab, see
>> https://help.github.com/articles/searching-issues-and-pull-requests/
>> <https://help.github.com/articles/searching-issues-and-pull-requests/>.
>> It lacks many other features of BZ: All categorization and status
>> tracking is by "labels" and they have no inherent hierarchy or
>> organization.
>>
>> So I think we're going to need our own bugtracker.
>>
>> BZ is Free and it should be fairly simple to get the Gnome bug team to
>> ship us a dump of our part of the database and set up a redirect once we
>> have our instance up and running. The web display on whatever it is that
>> GNU uses (e.g. https://savannah.gnu.org/bugs/?group=guile
>> <https://savannah.gnu.org/bugs/?group=guile>) but I dislike that it is
>> operated entirely by email. Mantis is popular but is managed by a bug
>> list. It's filterable to a fare-thee-well but lacks controlled
>> vocabularies on many of its fields so managing a large number of open
>> bugs is a PITA. RT (used by perl's CPAN) is also completely email driven.
>> Trac is a little less rudimentary than Github--it at least has categories
>> and status fields, but I don't believe it's capable of managing thousands
>> of bugs. SourceForge's built in tracker is on the same level as Github's
>> with less capable search.
>>
>> There's a sort of conceptual timeline on the DevelopmentInfrastructure
>> page but nothing concrete. I'd guess we have at least several months and
>> perhaps as long as a year to have a replacement up and running.
>>
>> Regards,
>> John Ralls
>> _______________________________________________
>> gnucash-devel mailing list
>> [hidden email]
>> https://lists.gnucash.org/mailman/listinfo/gnucash-devel
> _______________________________________________
> gnucash-devel mailing list
> [hidden email]
> https://lists.gnucash.org/mailman/listinfo/gnucash-devel

_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Gnome dropping Bugzilla

Adonay Felipe Nogueira
In reply to this post by John Ralls-2
There is also Debbugs ([[https://en.wikipedia.org/wiki/Debbugs]]), and
also GNU Savane (the software which is used to host Puszcza and GNU
Savannah) ([[https://savannah.gnu.org/projects/administration/]]).

We could also make use of GNU Savannah itself, no need to host our own,
and no need to go entirely to GitHub, while in any case we would still
keep compatibility with Git, and also have other stuff that GitHub
doesn't provide by default.

--
- [[https://libreplanet.org/wiki/User:Adfeno]]
- Palestrante e consultor sobre /software/ livre (não confundir com
  gratis).
- "WhatsApp"? Ele não é livre, por isso não uso. Iguais a ele prefiro
  GNU Ring, ou Tox. Quer outras formas de contato? Adicione o vCard
  que está no endereço acima aos teus contatos.
- Pretende me enviar arquivos .doc, .ppt, .cdr, ou .mp3? OK, eu
  aceito, mas não repasso. Entrego apenas em formatos favoráveis ao
  /software/ livre. Favor entrar em contato em caso de dúvida.
_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Gnome dropping Bugzilla

Geert Janssens-4
In reply to this post by John Ralls-2
On maandag 31 juli 2017 21:56:37 CEST John Ralls wrote:

> As I think everyone knows, we use bugzilla.gnome.org
> <http://bugzilla.gnome.org/> for bug and enhancement tracking.
>
> There's a new banner on every BZ page saying that Gnome plans to drop
> Bugzilla and the CGit repository browser, replacing them with Gitlab.
>
> That isn't going to work for us. I don't think it's going to work for Gnome,
> either, because a bug tracker that can't do word searches isn't capable of
> managing thousands of open bugs
> (https://docs.gitlab.com/ee/user/search/index.html
> <https://docs.gitlab.com/ee/user/search/index.html>), but that's not our
> problem.

From the link you pass I can't infer it's not possible to do word searches. On
the contrary the animated gif under "Search History" displays a search for the
word "something" (in addition to a label and milestone).

Perhaps I misunderstand what you mean here. Or are these features not
available in the community edition ?

> Our problem is that with our repository not at git.gnome.org
> <http://git.gnome.org/> there won't be a GnuCash project in GitLab and so
> there won't be a bug tracker. We'll need to get a new one.
>
Unless we set up a repository slave at GitLab just like we did with github ?

> Since we do mirror our repos to Github it is a viable option and it does at
> least have better search facilities (or at least they're better documented)
> that Gitlab, see
> https://help.github.com/articles/searching-issues-and-pull-requests/
> <https://help.github.com/articles/searching-issues-and-pull-requests/>. It
> lacks many other features of BZ: All categorization and status tracking is
> by "labels" and they have no inherent hierarchy or organization.
>
The adhoc categorization and status tracking by "labels" is indeed the weak
point IMO.

> So I think we're going to need our own bugtracker.
>
> BZ is Free and it should be fairly simple to get the Gnome bug team to ship
> us a dump of our part of the database and set up a redirect once we have
> our instance up and running.
A couple of years back I managed a bugzilla installation. It is pretty
straight-forward to do so. So having our own bugzilla is certainly one option.

The drawback is our limited server admin staff and hardware which has come up
a couple of times in different conversations. We have two servers (one
maintained by Linas and one maintained by Derek). Yet each service is hosted
only once and each server has only one admin. So our self-hosting scenario has
a redundancy issue. The more services we decide to host ourselves, the more
critical this becomes IMO.

> The web display on whatever it is that GNU
> uses (e.g. https://savannah.gnu.org/bugs/?group=guile
> <https://savannah.gnu.org/bugs/?group=guile>) but I dislike that it is
> operated entirely by email.

Completely agreed.

> Mantis is popular but is managed by a bug list.
> It's filterable to a fare-thee-well but lacks controlled vocabularies on
> many of its fields so managing a large number of open bugs is a PITA.

Ok

> RT (used by perl's CPAN) is also completely email driven.

Let's not do e-mail driven systems.

> Trac is a little
> less rudimentary than Github--it at least has categories and status fields,
> but I don't believe it's capable of managing thousands of bugs.
> SourceForge's built in tracker is on the same level as Github's with less
> capable search.

Bottom line is we're pretty used to bugzilla and the way it works. OTOH it
seems to be a big hurdle or many newcomers or casual users.

By the way there's a comparison of various (opensource and proprietary) bug
trackers on wikipedia in case we want more options to evaluate:
https://en.wikipedia.org/wiki/Comparison_of_issue-tracking_systems

At this point I'm having a hard time getting my attention on this. I'm mostly
focused on getting ready for the first 2.7 development snapshot.

>
> There's a sort of conceptual timeline on the DevelopmentInfrastructure page
> but nothing concrete. I'd guess we have at least several months and perhaps
> as long as a year to have a replacement up and running.

Which gives us some time to ponder on this. Hopefully.

Geert
_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Gnome dropping Bugzilla

Derek Atkins
Hi,

Geert Janssens <[hidden email]> writes:

[snip]

>> So I think we're going to need our own bugtracker.
>>
>> BZ is Free and it should be fairly simple to get the Gnome bug team to ship
>> us a dump of our part of the database and set up a redirect once we have
>> our instance up and running.
> A couple of years back I managed a bugzilla installation. It is pretty
> straight-forward to do so. So having our own bugzilla is certainly one option.
>
> The drawback is our limited server admin staff and hardware which has come up
> a couple of times in different conversations. We have two servers (one
> maintained by Linas and one maintained by Derek). Yet each service is hosted
> only once and each server has only one admin. So our self-hosting scenario has
> a redundancy issue. The more services we decide to host ourselves, the more
> critical this becomes IMO.

I'll just point out that, while he was around, JSled had root access to
code.  So we DID have multiple administrators.  Of course that doesn't
help when there's a hardware, power, or local ISP failure.  If there is
another core dev that wants to co-admin code we can talk about access.

Of course this doesn't help with the service redundancy.  If there IS a
local issue (hardware, power, network) then the service will go offline
until it can be repaired.  Granted, I have a large-scale UPS and a
natural-gas-powered backup generator so there is no longer a local power
outage issue.  However HW and ISP issues are a bit more out of my
control.

[snip]
> Bottom line is we're pretty used to bugzilla and the way it works. OTOH it
> seems to be a big hurdle or many newcomers or casual users.
>
> By the way there's a comparison of various (opensource and proprietary) bug
> trackers on wikipedia in case we want more options to evaluate:
> https://en.wikipedia.org/wiki/Comparison_of_issue-tracking_systems
>
> At this point I'm having a hard time getting my attention on this. I'm mostly
> focused on getting ready for the first 2.7 development snapshot.

As I said in a previous email, I'm happy to set up Bugzilla.

I would set it up from the beginning such that ALL accounts required
admin approval to prevent spam.

I think the hardest part would be working with the gnome bugzilla people
to get a partial DB dump from them.

>> There's a sort of conceptual timeline on the DevelopmentInfrastructure page
>> but nothing concrete. I'd guess we have at least several months and perhaps
>> as long as a year to have a replacement up and running.
>
> Which gives us some time to ponder on this. Hopefully.
>
> Geert

-derek

--
       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
       Member, MIT Student Information Processing Board  (SIPB)
       URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
       [hidden email]                        PGP key available
_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Gnome dropping Bugzilla

Bruce-Robert Fenn Pocock
On Mon, Aug 7, 2017, 10:23 Derek Atkins <[hidden email]> wrote:

> Hi,
>
> Geert Janssens <[hidden email]> writes:
>
> [snip]
> ….
> >
> > The drawback is our limited server admin staff and hardware which has
> come up
> > a couple of times in different conversations. We have two servers (one
> > maintained by Linas and one maintained by Derek). Yet each service is
> hosted
> > only once and each server has only one admin. So our self-hosting
> scenario has
> > a redundancy issue. The more services we decide to host ourselves, the
> more
> > critical this becomes IMO.
>
> …
>
> Of course this doesn't help with the service redundancy.  If there IS a
> local issue (hardware, power, network) then the service will go offline
> until it can be repaired.  Granted, I have a large-scale UPS and a
> natural-gas-powered backup generator so there is no longer a local power
> outage issue.  However HW and ISP issues are a bit more out of my
> control.


I could provide a mirror site for redundancy with my shared hosting (at
Dreamhost), if that would help. Perhaps just a "hot backup" that could be
enabled if you did lose connectivity or so far a while, rather than working
up a more complicated High Availability system. I assume a brief outage
(eg, hour?) of the bug tracker would not be critical to life.
_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Redundant infrastructure (was:Re: Gnome dropping Bugzilla)

Geert Janssens-4
On maandag 7 augustus 2017 18:17:38 CEST Bruce-Robert Fenn Pocock wrote:

> On Mon, Aug 7, 2017, 10:23 Derek Atkins <[hidden email]> wrote:
> > Hi,
> >
> > Geert Janssens <[hidden email]> writes:
> >
> > [snip]
> > ….
> >
> > > The drawback is our limited server admin staff and hardware which has
> >
> > come up
> >
> > > a couple of times in different conversations. We have two servers (one
> > > maintained by Linas and one maintained by Derek). Yet each service is
> >
> > hosted
> >
> > > only once and each server has only one admin. So our self-hosting
> >
> > scenario has
> >
> > > a redundancy issue. The more services we decide to host ourselves, the
> >
> > more
> >
> > > critical this becomes IMO.
> >
> > …
> >
> > Of course this doesn't help with the service redundancy.  If there IS a
> > local issue (hardware, power, network) then the service will go offline
> > until it can be repaired.  Granted, I have a large-scale UPS and a
> > natural-gas-powered backup generator so there is no longer a local power
> > outage issue.  However HW and ISP issues are a bit more out of my
> > control.
>
> I could provide a mirror site for redundancy with my shared hosting (at
> Dreamhost), if that would help. Perhaps just a "hot backup" that could be
> enabled if you did lose connectivity or so far a while, rather than working
> up a more complicated High Availability system. I assume a brief outage
> (eg, hour?) of the bug tracker would not be critical to life.

That's very kind. For the record I have two redundant servers myself that can
be configured to run as backups/mirrors/whatever of the gnucash
infrastructure.

This is something I'd like to pick up some time later, when gnucash 2.7/.28
are taking less of my time. Those are top priority now as several distros are
starting to drop gnucash due to the webkit obsolescence.

Geert

_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Gnome dropping Bugzilla

John Ralls-2
In reply to this post by Geert Janssens-4

> On Aug 7, 2017, at 2:24 PM, Geert Janssens <[hidden email]> wrote:
>
> On maandag 31 juli 2017 21:56:37 CEST John Ralls wrote:
>> As I think everyone knows, we use bugzilla.gnome.org
>> <http://bugzilla.gnome.org/> for bug and enhancement tracking.
>>
>> There's a new banner on every BZ page saying that Gnome plans to drop
>> Bugzilla and the CGit repository browser, replacing them with Gitlab.
>>
>> That isn't going to work for us. I don't think it's going to work for Gnome,
>> either, because a bug tracker that can't do word searches isn't capable of
>> managing thousands of open bugs
>> (https://docs.gitlab.com/ee/user/search/index.html
>> <https://docs.gitlab.com/ee/user/search/index.html>), but that's not our
>> problem.
>
> From the link you pass I can't infer it's not possible to do word searches. On
> the contrary the animated gif under "Search History" displays a search for the
> word "something" (in addition to a label and milestone).
>
> Perhaps I misunderstand what you mean here. Or are these features not
> available in the community edition ?
>
>> Our problem is that with our repository not at git.gnome.org
>> <http://git.gnome.org/> there won't be a GnuCash project in GitLab and so
>> there won't be a bug tracker. We'll need to get a new one.
>>
> Unless we set up a repository slave at GitLab just like we did with github ?
>
>> Since we do mirror our repos to Github it is a viable option and it does at
>> least have better search facilities (or at least they're better documented)
>> that Gitlab, see
>> https://help.github.com/articles/searching-issues-and-pull-requests/
>> <https://help.github.com/articles/searching-issues-and-pull-requests/>. It
>> lacks many other features of BZ: All categorization and status tracking is
>> by "labels" and they have no inherent hierarchy or organization.
>>
> The adhoc categorization and status tracking by "labels" is indeed the weak
> point IMO.
>
>> So I think we're going to need our own bugtracker.
>>
>> BZ is Free and it should be fairly simple to get the Gnome bug team to ship
>> us a dump of our part of the database and set up a redirect once we have
>> our instance up and running.
> A couple of years back I managed a bugzilla installation. It is pretty
> straight-forward to do so. So having our own bugzilla is certainly one option.
>
> The drawback is our limited server admin staff and hardware which has come up
> a couple of times in different conversations. We have two servers (one
> maintained by Linas and one maintained by Derek). Yet each service is hosted
> only once and each server has only one admin. So our self-hosting scenario has
> a redundancy issue. The more services we decide to host ourselves, the more
> critical this becomes IMO.
>
>> The web display on whatever it is that GNU
>> uses (e.g. https://savannah.gnu.org/bugs/?group=guile
>> <https://savannah.gnu.org/bugs/?group=guile>) but I dislike that it is
>> operated entirely by email.
>
> Completely agreed.
>
>> Mantis is popular but is managed by a bug list.
>> It's filterable to a fare-thee-well but lacks controlled vocabularies on
>> many of its fields so managing a large number of open bugs is a PITA.
>
> Ok
>
>> RT (used by perl's CPAN) is also completely email driven.
>
> Let's not do e-mail driven systems.
>
>> Trac is a little
>> less rudimentary than Github--it at least has categories and status fields,
>> but I don't believe it's capable of managing thousands of bugs.
>> SourceForge's built in tracker is on the same level as Github's with less
>> capable search.
>
> Bottom line is we're pretty used to bugzilla and the way it works. OTOH it
> seems to be a big hurdle or many newcomers or casual users.
>
> By the way there's a comparison of various (opensource and proprietary) bug
> trackers on wikipedia in case we want more options to evaluate:
> https://en.wikipedia.org/wiki/Comparison_of_issue-tracking_systems
>
> At this point I'm having a hard time getting my attention on this. I'm mostly
> focused on getting ready for the first 2.7 development snapshot.
>
>>
>> There's a sort of conceptual timeline on the DevelopmentInfrastructure page
>> but nothing concrete. I'd guess we have at least several months and perhaps
>> as long as a year to have a replacement up and running.
>
> Which gives us some time to ponder on this. Hopefully.



It's my understanding that Gnome intends to run their own instance of the Gitlab software, so setting up a mirror at Gitlab itself won't get us integration with Gnome's instance. We'd need to set up a mirror at git.gnome.org <http://git.gnome.org/>. We could use my ID short term and just do it, but I think that that might be politically unwise. We'd need to negotiate with the admin folks.

Your concerns about admin coverage is well taken, especially with the recent outages that Linas recently suffered while he was on extended travel.

Regards,
John Ralls

_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Redundant infrastructure

Derek Atkins
In reply to this post by Geert Janssens-4
Geert Janssens <[hidden email]> writes:

>> > Of course this doesn't help with the service redundancy.  If there IS a
>> > local issue (hardware, power, network) then the service will go offline
>> > until it can be repaired.  Granted, I have a large-scale UPS and a
>> > natural-gas-powered backup generator so there is no longer a local power
>> > outage issue.  However HW and ISP issues are a bit more out of my
>> > control.
>>
>> I could provide a mirror site for redundancy with my shared hosting (at
>> Dreamhost), if that would help. Perhaps just a "hot backup" that could be
>> enabled if you did lose connectivity or so far a while, rather than working
>> up a more complicated High Availability system. I assume a brief outage
>> (eg, hour?) of the bug tracker would not be critical to life.
>
> That's very kind. For the record I have two redundant servers myself that can
> be configured to run as backups/mirrors/whatever of the gnucash
> infrastructure.
>
> This is something I'd like to pick up some time later, when gnucash 2.7/.28
> are taking less of my time. Those are top priority now as several distros are
> starting to drop gnucash due to the webkit obsolescence.

Linas and I have talked about it as well.

The problem, of course, is that it's easy to set up load-balancing
redundancy (with two separate systems in separate locations) both
serving requests..  But this really only works for static (or
quazi-static) content.

I'm not sure how we would accomplish that with the Wiki or even GIT,
where there's a read-write backend.  For something backed by a database
you would need to run multiple instances of MySQL with concurrency
behind them.  I'm not enough of a MySQL guru to set that up.

Similarly, I'm not sure how we would replicate the Mailman instances.
We could certainly set up a redundant MX record, but SMTP already holds
mail for ~5 days so should handle relatively short outages.

The other option is to have a "hot spare" running, which is taking
updates from the primary but isn't serving any content.  But I don't
know how to handle an "automated cutover" in the case of a failure.

All the solutions I know about are for multiple instances in the same
data center.  I have no idea how to do it in a globally distributed
manner.

> Geert

-derek

--
       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
       Member, MIT Student Information Processing Board  (SIPB)
       URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
       [hidden email]                        PGP key available
_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Redundant infrastructure

gnucash-10
On Wed, 9 Aug 2017, Derek Atkins wrote:
> All the solutions I know about are for multiple instances in the same
> data center.  I have no idea how to do it in a globally distributed
> manner.

Failover can be setup via DNS, to ping/check a host and then swap IPs if
the first host doesn't respond, and theb you can decide what you want to
do when the first host comes back up, probably auto-switching back is
harder to setup due to changes that happen on the second server while thw
first is down.

dnsmadeeasy.com has the cheapest (and actually best) service for this (as
well as other things - I've used them commercially for ten years or so,
and had almost no issues.

But, for gnucash, I'd think you don't really need a high availability
solution like this.  I'd expect good backups to be good enough,
particularly if it is a virtual server that can be spun back up from the
backup.  But, even real hardware is probably good enough - there probably
aren't that many urgent requests that come that can't wait a day or two.
And DNS could always be manually changed in the worst case.

All that said, if you want to go that route, I have experience with this
and can spend time or at least recommend software options.


--
Jon Daley
http://jon.limedaley.com
~~
We are trying to get unemployment to go up and
   I think we're going to succeed.
-- Ronald Reagan
_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Redundant infrastructure

Derek Atkins
Hi,

Jon Daley <[hidden email]> writes:

> On Wed, 9 Aug 2017, Derek Atkins wrote:
>> All the solutions I know about are for multiple instances in the same
>> data center.  I have no idea how to do it in a globally distributed
>> manner.
>
> Failover can be setup via DNS, to ping/check a host and then swap IPs
> if the first host doesn't respond, and theb you can decide what you
> want to do when the first host comes back up, probably auto-switching
> back is harder to setup due to changes that happen on the second
> server while thw first is down.
>
> dnsmadeeasy.com has the cheapest (and actually best) service for this
> (as well as other things - I've used them commercially for ten years
> or so, and had almost no issues.

Right now Linas runs our DNS service.  I suspect we would have to do an
akamai-like www.gnucash.org CNAME www.gnucash.dnsmadeeasy.com or
some-such to get the load-balancing working.  I'm not sure I really want
a third-party out of our control to be able to repoint our services.

> But, for gnucash, I'd think you don't really need a high availability
> solution like this.  I'd expect good backups to be good enough,
> particularly if it is a virtual server that can be spun back up from
> the backup.  But, even real hardware is probably good enough - there
> probably aren't that many urgent requests that come that can't wait a
> day or two. And DNS could always be manually changed in the worst
> case.

Backups for www are easy -- the website is completely in GIT.
Backups for code are harder, but I have a nightly backup to another
system, but it's still local to my network.
Neither of these are "decent" for disaster recovery.

> All that said, if you want to go that route, I have experience with
> this and can spend time or at least recommend software options.

I think we would first need to decide what we actually want/need, and
then we can look at what we have and determine what steps will be
necessary to take what we have and get what we want/need.

I don't think we've fully analyzed the first step, yet, even though
we're talking about the second.

-derek

--
       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
       Member, MIT Student Information Processing Board  (SIPB)
       URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
       [hidden email]                        PGP key available
_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Loading...