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

[Eli Schwartz]

On 11/14/2017 02:30 PM, Jelle van der Waa wrote:
> 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.

We've never autoclosed bugs just because they are old, why start now
*just because* we are migrating?

Then too there are not-yet-implemented feature requests for
pacman/aurweb/$project.

I'd prefer we migrated all open bugs and left them open, possibly
excluding old bugs filed under the kernel category as they have an
alarming tendency to be upstream issues and/or hardware issues and
anyway are questionably relevant considering the numerous updates.

Possibly also extend that to also excluding open bugs that are assigned
as upstream issues, as those usually have no real purpose other than to
maybe track upstream and backport a fix as soon as one is available.

If we have too many unresolved open bugs (which we do), they need to be
triaged and dealt with (something I'd like to get around to doing and
which I have already picked some low-hanging fruit).

> # 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
>
> Input would be welcome, on what we should migrate from flyspray and
> what products we should define.

netctl/mkinitcpio/devtools/dbscripts/namcap/pyalpm

These are currently grouped together alongside core/extra as a component
in the Arch Linux project, but if they don't each deserve their own
project they can probably be components in an "Arch Projects" project.

-- 
Eli Schwartz

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://lists.archlinux.org/pipermail/arch-dev-public/attachments/20171114/ca386ea7/attachment.asc>