[arch-dev-public] Switching the bugtracker to Bugzilla

Lukas Fleischer lfleischer at archlinux.org
Wed Nov 15 08:07:27 UTC 2017


On Tue, 14 Nov 2017 at 20:30:21, Jelle van der Waa wrote:
> It's time to switch our to something which is maintained and can be extended to
> our wishes. Flyspray isn't actively maintained, has had several security issues [1] [2].
> [...]

Great!

> # Migration
> 
> There are several options for migrating the bug history to Bugzilla and a few options are under
> debate. (input welcome)
> 
> * No migration at all
> * Migrate open bugs
> * Migrate open bugs and auto-closing them
> * Migrate all bugs
> * Migrate all bugs and auto-closing them
> 
> In either case, I believe it would be nice to "archive" the current bugtracker and make it read
> only.

Doing no migration and having an archive of the current tickets sounds
like a good idea to me -- I can only talk about the aurweb project and
the packages projects, though -- maintainers of other components might
disagree.

After the migration, I would go through the open aurweb tickets on the
Flyspray archive, create new tickets for the most important issues
(should not be more than 10), fix/implement some of the easy stuff and
close the tickets which I think are not worth fixing or implementing.

> # User migration
> 
> User migration should be possible as well, except migrating the password, a mass password reset
> would be wise. Since I'm not sure what kind of old hashing method / salt flyspray uses.

Sounds good to me, although I do not see the benefit of doing this if we
do not migrate tickets. If users need to reset their passwords, they can
as well reregister. There aren't too many things to configure and the
profile settings in Flyspray will likely not match what you can
configure in Bugzilla anyways.

Generally speaking, I am in favor of setting up a fresh Bugzilla
instance and not doing any sort of migration. The idea of switching to a
new bug tracker came up at least four years ago and my feeling is that
all this migration work is what was holding it back for a long time.
However, we should make sure that the old Flyspray URLs still work (and
redirect to the Flyspray archive).

> 
> # Migration Projects
> 
> Bugzilla has a concept of products with components, so for all our packages we can create a
> component counterpart. It should be possible to auto-assign bugs with the pkgname <-> maintainer
> information from archweb.
> 
> Possible products would be.
> 
> # Products
> 
> * Arch packages (core/extra or split this up)
> * Community packages (community)
> * Pacman
> * AURWeb
> * Keyring
> * Archweb (new)
> * Arch VM / Docker images (new)
> * Release engineering

Sounds good to me. I would split [core] and [extra]. I would also call
the packages projects "[core] packages", "[extra] packages" and
"[community] packages"; unless there are technical limitations
preventing the use of brackets. These brackets make it much clearer that
the names are referring to pacman repositories; and to a novice Arch
user, it may not be 100% clear what a "community package" or an "extra
package" is.

Best regards,
Lukas


More information about the arch-dev-public mailing list