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 gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
