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 > gnucash-devel@gnucash.org > https://lists.gnucash.org/mailman/listinfo/gnucash-devel > -- Derek Atkins 617-623-3745 de...@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant _______________________________________________ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
