To clarify the timeline. There is no fix timespan between point 1) and 2) in my last mail. We'll not migrate the bugtracker on/the following days after the bug wrangling day. The migration will not take place until we have a working new bugtracker to replace Flyspray with.

On 30/08/2020 16.21, Jelle van der Waa wrote:

On 30/08/2020 01:02, Frederik Schwan via arch-dev-public wrote:

...

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 :/ This is coordinated on #archlinux-bugs on Freenode right?

Yes, I'll send out an arch announce draft when this discussion is over which includes that we are available on the #archlinux-bugs channel for questions.

...

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. I think we have a lot of issues which are fixable but the packager has not been able to do it yet. In my opinion we should also try to fix as much packages as possible, which everyone should be able to do.

Thanks, I'll add that. "Any bug shall be fixed if a fix is available and the maintainer just hasn't had time to apply it yet."

...

b) Any infrastructure ticket shall not be touched. This will be handled by $DevOps.

What infrastructure tickets are there on flyspray? What about other projects such as aurweb, pacman etc?

That was a bad phrase - sorry. "We focus on the [community], [core], [extra] and [multilib] bugs in the 'Arch Linux' and the 'Community Packages' project." I don't want to stop anyone from reviewing pacman or release engineering bugs, but it's rather small and in good shape compared to the big two trackers. Cheers, Frederik

On 30/08/2020 01:02, Frederik Schwan via arch-dev-public wrote:

Hi folks, I'd like to migrate the beloved Flyspray bug tracker to our new Gitlab instance.

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. b) Any infrastructure ticket shall not be touched. This will be handled by $DevOps.

2) Afterwards we will point the bug tracker links in the Archweb to the new location and opening new tickets in Flyspray will be disabled. The project structure of the future Gitlab bug tracker will be discussed in a seperate mail and is not part of this mail(thread).

3) When enough tickets are closed or when $DevOps is tired enough of Flyspray, we'll migrate the rest of the tickets to Gitlab. We seek to keep Flyspray as a static homepage to allow the reference in the new bug tracker to old tickets and to keep the integrity of search engine results.

Please make sure you all have a working account at our Gitlab instance.

Cheers, Frederik

I like the idea of moving away from flyspray as a bugtracking system. Why not first move the packages in gitlab so you can use the bugtracker per package. That will give a proper corrolation and you even can link tickets together if they were created for the wrong package. For infrastructure and even more administrative ticketing you can just setup a separate gitlab repo to do just that. I don't think moving from flyspray 'community packages' bugtracker to a gitlab 'community packages' bugtracker will be much of an improvement. Greets, Ike

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