This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------oL7N2S8w5h1bPVRgwYVNpdTR
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

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
[email protected]
Gentoo Linux developer (Python, Arch Teams, GURU)

--------------oL7N2S8w5h1bPVRgwYVNpdTR--

-----BEGIN PGP SIGNATURE-----

iQEzBAEBCgAdFiEE/axFlFuH2ptjtO5EAqCvUD0SBQQFAmJjxhQACgkQAqCvUD0S BQSyJwf/QC+baqp9gOijwhnbDYb0R91cvLgS7PgwrFRL1ZvUlSAFm9zCeXuhtvdr fBqb5dCY+YEcIcsL5fmF1/w3HdUucldbX9ObFu2SOsUzcvxoXFIgyL9wH99mZDZi DHMfta5ZxTZfhtPTLhsJWwC8vSjxtguYYXHwFZ3pvC7MjOd/jmMFRjapeNomGTI9 86VLefP4NXfwiySM1zWFf4M83xta0pnTj2eep7Jg7L9SGv2V+zGpnhwR9aQ7GldV J1WlZ9B6pznDfz2qdisqVJPv/1njgSUiyIdMu3tppCTB19p4hh1WXF3xM4+Cn6Ib Nhvc2LsM6NMe0Ap4I6sq9sugd1Km4A==
=9s0j
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)