[arch-dev-public] Bug tracker migration

[Frederik Schwan]

On 30/08/2020 20.58, Eli Schwartz via arch-dev-public wrote:
> On 8/29/20 7:02 PM, Frederik Schwan via arch-dev-public wrote:
>> Hi folks,
>> I'd like to migrate the beloved Flyspray bug tracker to our new Gitlab instance.
> This decision did not take place with input from the people affected by
> such a move, who may or may not want to use Gitlab. Can you clarify for
> the rest of us, which parties actually *did* have input, and *where*
> this took place? Announcing it as a foregone conclusion seems premature.

I got in touch with DevOps when gitlab was about to be production ready.
That time there was no doubt that we migrate most of our services to gitlab including
the bug tracker. So I thought this have been decided in the past before I got
my hands dirty.

> We also don't know how it's supposed to work given gitlab is a git
> forge, and most things aren't actually git repos as of now. Some things
> never will be because they aren't even code.
> 
> Furthermore it's straight-up a non-starter until such time as users
> interested in reporting bugs can open up accounts with which to open
> bugs. Currently https://gitlab.archlinux.org is closed to registration
> and relies on SSO accounts exclusive to internal team members..

I'd like to do a bug day even though there is no consent about moving to gitlab
since there is no immediate implication of the bug day. I could have just announced
the bug day without mentioning any migration, but that would have ignored the
problem that we should minimize the amount of data to move to a new platform -
whatever platform that will be.

>> TLDR:
>> - Bug wrangling day on the 13th of September; see 1)
>> - Flyspray will be read-only after we rewrite the Archweb URLs
>> - new bug tracker -> Gitlab
>>
>>
>> 1) I'd like to hold a bug wrangling day, where our goal is to close as many bugs as possible.
>>    Any TU, Reporter and bug wrangler is invited to help out :) Unfortunately I can't offer any cookies that day :/
>>    
>>    Rules:
>>      a) Bug with no reply for at least 6 months which has been submitted for a different version than the current one in 
>>         the repos shall be closed with a message that a reopen request may be filled if this issue is still present.
> Bug wrangling is always a good thing, we don't need to limit it to
> September 13, but the usual approach we take is to investigate old bugs
> and close them with "I cannot reproduce the bug, it seems to be fixed",
> rather than closing them with "we do not care about bugs that weren't
> fixed in six months".
> 
> We *have* had other bug days, you know. They weren't "lets close as many
> bugs as possible", they were "let's dig into old bugs and figure out
> what to do about them, triage them if possible, hunt down resolutions,
> or verify if they've been fixed".
> 
> I am vehemently opposed to the concept of "stale bots", which are very
> popular on github and gitlab but which are merely the sign of a
> developer team that cares more about looking like there aren't so many
> bugs than actually fixing them.

I agree with you that stale bots are bad practice in general. I don't like to see them in
our projects in the future either.
But we need to solve the problem that there are 2232 open bugs as of today, with many of them
referencing very old package versions and lots of them being assigned to the wrong maintainer.
I don't see us researching all of them for a resolution within the next 365 days and neither
migrating all of them.
My intention is to close bugs that are obviously outdated e.g. FS#49646 without researching
for hours when qemu stopped freezing exactly.
For me this is a one time thing to help the migration. I don't want to make this a general
bug wrangling rule.

I think the addition to rule a) which I posted earlier
> "Any bug shall be fixed if a fix is available and the maintainer just hasn't had time to apply it yet."
should make sure that we refrain from just closing everything but have a look at
the newer package and check if they are fixed.
 
>>      b) Any infrastructure ticket shall not be touched. This will be handled by $DevOps.
> Also tickets opened against things other than packages, for instance the
> *entire* Pacman and Aurweb projects.

Noted. I'd like to focus on "Community Packages" and "Arch Linux" only.

Frederik

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