[gentoo-dev] [RFC] Change the stabilization request flows

[gentoo-dev] [RFC] Change the stabilization request flows

[Arthur Zamarin]

[-- Attachment #1.1: Type: text/plain, Size: 5037 bytes --]

Hi All!

As a result of a premature stabilization CC-ARCHES without
acknowledgments from maintainers on a bug in last week, and after leio
suggested on IRC a change of flows, I want to suggest multiple ideas and
get your responses and comments.

As some background, we have a tool called nattka [1], which periodically
scans all stabilization and keywording bugs, sanity checks them and CC
all relevant arches when the bug is "ready".
Currently the needed rules to mark the bug as ready are having CC-ARCHES
is keywords, having correctly formatted package-list, and having the bug
assigned.
Around a month ago, I have added a new addition to nattka [2], which
auto CC maintainers of all packages in package-list. This was so
maintainers are informed of changes to their package.
But as you can understand, this isn't error-proof, as even if all
maintainers were CC (sadly this didn't work for the bug mentioned above,
but doesn't matter for the discussion), the Arches Testers can be too
fast and finish the bug before maintainers had time to NAK the process.

--------------------------------

The first flow I want to introduce is when nattka sees a bug with
CC-ARCHES in keyword, but not all maintainers were CC, nattka will CC
all maintainers, drop the CC-ARCHES, and comment something a long the
lines "wait for maintainers to ACK by adding CC-ARCHES keyword" (of
course the text can improve).

What are the effects from that addition? In case someone create a
request and mistakenly missed a maintainer, the process will pause and
wait for re-addition.
But if the reporter of bug fills all fields correctly and CC all
expected maintainers, nattka won't wait before marking the bug "ready".
We have teams and people who know what they do, and file massive amounts
of stabilization requests, with knowledge what they do. I don't want to
hinder this workflow and make it harder. Also the check who can add the
CC-ARCHES keyword is very hard to define (was he part of the project,
was he allowed on IRC as one time proxy, maintainer-timeout, etc).
I believe all gentoo developers has the knowledge and responsibility, so
that if they do a mistake, they will need to follow it and fix it, as
appropriate in each case of bad results.

--------------------------------

Another idea, given by mgorny and sam on IRC, was to use flags on
bugzilla. The same way we have currently a flag for "sanity-check" and
"bugday", we can do a flag for maintainer ACK.

The advantage of using a flag instead of keyword, is the possibility to
restrict access to this flag to only users with "editbugs" permission.
With all dues respect, we can't expect the same responsibility from
non-gentoo-devs as from gentoo-devs, from those we can expect,
"editbugs" will be fine.

If we decide to go with a flag, we will have backward compatible nattka
to work with "old" keyword based way, and maybe we will use nattka to
"migrate" the "old" bugs to the new way.

--------------------------------

I also want to suggest using the deadline field of a bug. For those that
don't know, you can set the deadline for a bug by clicking the "show
time tracking data" between the bug info and comments. But I want to use
this field in the opposite meaning, as "the minimal date we can mark
this bug ready".
Mainly at java packages stablereq bugs, I saw vaukai creating a bug, and
stating "starting from xxx date", which I think is very nice usage, but
a user can forget he marked that package. On implementation side, nattka
will sanity check the bug, but won't CC all arch teams until this date
arrives.
I think this is a very small feature, but will be nice to have for such
users. My only disadvantage is using misleading now name of "deadline".

--------------------------------

After such a changes every stabilization bug will have the following
possible states:
1. "Bad formatted" bug (not assigned or wrong formatted package list) -
Do nothing
2. filed full bug, but without all maintainers included --> CC all,
comment on missing maintainers, and drop ACK flag (CC-ARCHES / the flag)
3. file full bug, with all maintainers, without ACK --> do sanity-checks
but if all ok do nothing
4. file full bug, with all maintainers, with ACK, with deadline in
future --> do sanity-checks but if all ok do nothing
5. file full bug, with all maintainers, with ACK, without deadline or
one in past --> do sanity-checks, and CC all arch teams if ok

--------------------------------

Thank you for reading this wall of text. I wanted to give the most
information that I could write so we have informative discussion. I also
want to remind that in case you miss a feature, open a discussion or an
issue at [1] - we all want to have better tooling for Gentoo.

[1] https://github.com/mgorny/nattka
[2]
https://github.com/mgorny/nattka/commit/de12fad667c9239c757f4f637d17ceef159ad38b

-- 
Arthur Zamarin
arthurzam@gentoo.org
Gentoo Linux developer (Python, Arch Teams, GURU)

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [gentoo-dev] [RFC] Change the stabilization request flows

[Ulrich Mueller]

[-- Attachment #1: Type: text/plain, Size: 552 bytes --]

>>>>> On Sat, 23 Apr 2022, Arthur Zamarin wrote:

> The first flow I want to introduce is when nattka sees a bug with
> CC-ARCHES in keyword, but not all maintainers were CC, nattka will CC
> all maintainers, drop the CC-ARCHES, and comment something a long the
> lines "wait for maintainers to ACK by adding CC-ARCHES keyword" (of
> course the text can improve).

That's not entirely fool-proof. Sometimes a maintainer's description
suggests that they shouldn't be CCed. (Maybe we need an additional tag
for this to make it machine readable?)

Ulrich

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 507 bytes --]

Re: [gentoo-dev] [RFC] Change the stabilization request flows

[Arthur Zamarin]

[-- Attachment #1.1: Type: text/plain, Size: 854 bytes --]

On 23/04/2022 14.22, Ulrich Mueller wrote:
>>>>>> On Sat, 23 Apr 2022, Arthur Zamarin wrote:
> 
>> ...
> 
> That's not entirely fool-proof. Sometimes a maintainer's description
> suggests that they shouldn't be CCed. (Maybe we need an additional tag
> for this to make it machine readable?)

I'm all for more machine readable metadata.xml with extra tags for
things like that. Also, is that common to have such things? Why would
you be marked as maintainer and not be CC for stabilization requests? At
least to my understanding of maintainer "job" at Gentoo seem to contradict?

Also, if we decide (at least in the current thread) to add a new tag to
mark this person as non-CC - what is the approval process for such a change?

> Ulrich


-- 
Arthur Zamarin
arthurzam@gentoo.org
Gentoo Linux developer (Python, GURU, Arch Teams)

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]