| 1 |
Hi All! |
| 2 |
|
| 3 |
As a result of a premature stabilization CC-ARCHES without |
| 4 |
acknowledgments from maintainers on a bug in last week, and after leio |
| 5 |
suggested on IRC a change of flows, I want to suggest multiple ideas and |
| 6 |
get your responses and comments. |
| 7 |
|
| 8 |
As some background, we have a tool called nattka [1], which periodically |
| 9 |
scans all stabilization and keywording bugs, sanity checks them and CC |
| 10 |
all relevant arches when the bug is "ready". |
| 11 |
Currently the needed rules to mark the bug as ready are having CC-ARCHES |
| 12 |
is keywords, having correctly formatted package-list, and having the bug |
| 13 |
assigned. |
| 14 |
Around a month ago, I have added a new addition to nattka [2], which |
| 15 |
auto CC maintainers of all packages in package-list. This was so |
| 16 |
maintainers are informed of changes to their package. |
| 17 |
But as you can understand, this isn't error-proof, as even if all |
| 18 |
maintainers were CC (sadly this didn't work for the bug mentioned above, |
| 19 |
but doesn't matter for the discussion), the Arches Testers can be too |
| 20 |
fast and finish the bug before maintainers had time to NAK the process. |
| 21 |
|
| 22 |
-------------------------------- |
| 23 |
|
| 24 |
The first flow I want to introduce is when nattka sees a bug with |
| 25 |
CC-ARCHES in keyword, but not all maintainers were CC, nattka will CC |
| 26 |
all maintainers, drop the CC-ARCHES, and comment something a long the |
| 27 |
lines "wait for maintainers to ACK by adding CC-ARCHES keyword" (of |
| 28 |
course the text can improve). |
| 29 |
|
| 30 |
What are the effects from that addition? In case someone create a |
| 31 |
request and mistakenly missed a maintainer, the process will pause and |
| 32 |
wait for re-addition. |
| 33 |
But if the reporter of bug fills all fields correctly and CC all |
| 34 |
expected maintainers, nattka won't wait before marking the bug "ready". |
| 35 |
We have teams and people who know what they do, and file massive amounts |
| 36 |
of stabilization requests, with knowledge what they do. I don't want to |
| 37 |
hinder this workflow and make it harder. Also the check who can add the |
| 38 |
CC-ARCHES keyword is very hard to define (was he part of the project, |
| 39 |
was he allowed on IRC as one time proxy, maintainer-timeout, etc). |
| 40 |
I believe all gentoo developers has the knowledge and responsibility, so |
| 41 |
that if they do a mistake, they will need to follow it and fix it, as |
| 42 |
appropriate in each case of bad results. |
| 43 |
|
| 44 |
-------------------------------- |
| 45 |
|
| 46 |
Another idea, given by mgorny and sam on IRC, was to use flags on |
| 47 |
bugzilla. The same way we have currently a flag for "sanity-check" and |
| 48 |
"bugday", we can do a flag for maintainer ACK. |
| 49 |
|
| 50 |
The advantage of using a flag instead of keyword, is the possibility to |
| 51 |
restrict access to this flag to only users with "editbugs" permission. |
| 52 |
With all dues respect, we can't expect the same responsibility from |
| 53 |
non-gentoo-devs as from gentoo-devs, from those we can expect, |
| 54 |
"editbugs" will be fine. |
| 55 |
|
| 56 |
If we decide to go with a flag, we will have backward compatible nattka |
| 57 |
to work with "old" keyword based way, and maybe we will use nattka to |
| 58 |
"migrate" the "old" bugs to the new way. |
| 59 |
|
| 60 |
-------------------------------- |
| 61 |
|
| 62 |
I also want to suggest using the deadline field of a bug. For those that |
| 63 |
don't know, you can set the deadline for a bug by clicking the "show |
| 64 |
time tracking data" between the bug info and comments. But I want to use |
| 65 |
this field in the opposite meaning, as "the minimal date we can mark |
| 66 |
this bug ready". |
| 67 |
Mainly at java packages stablereq bugs, I saw vaukai creating a bug, and |
| 68 |
stating "starting from xxx date", which I think is very nice usage, but |
| 69 |
a user can forget he marked that package. On implementation side, nattka |
| 70 |
will sanity check the bug, but won't CC all arch teams until this date |
| 71 |
arrives. |
| 72 |
I think this is a very small feature, but will be nice to have for such |
| 73 |
users. My only disadvantage is using misleading now name of "deadline". |
| 74 |
|
| 75 |
-------------------------------- |
| 76 |
|
| 77 |
After such a changes every stabilization bug will have the following |
| 78 |
possible states: |
| 79 |
1. "Bad formatted" bug (not assigned or wrong formatted package list) - |
| 80 |
Do nothing |
| 81 |
2. filed full bug, but without all maintainers included --> CC all, |
| 82 |
comment on missing maintainers, and drop ACK flag (CC-ARCHES / the flag) |
| 83 |
3. file full bug, with all maintainers, without ACK --> do sanity-checks |
| 84 |
but if all ok do nothing |
| 85 |
4. file full bug, with all maintainers, with ACK, with deadline in |
| 86 |
future --> do sanity-checks but if all ok do nothing |
| 87 |
5. file full bug, with all maintainers, with ACK, without deadline or |
| 88 |
one in past --> do sanity-checks, and CC all arch teams if ok |
| 89 |
|
| 90 |
-------------------------------- |
| 91 |
|
| 92 |
Thank you for reading this wall of text. I wanted to give the most |
| 93 |
information that I could write so we have informative discussion. I also |
| 94 |
want to remind that in case you miss a feature, open a discussion or an |
| 95 |
issue at [1] - we all want to have better tooling for Gentoo. |
| 96 |
|
| 97 |
[1] https://github.com/mgorny/nattka |
| 98 |
[2] |
| 99 |
https://github.com/mgorny/nattka/commit/de12fad667c9239c757f4f637d17ceef159ad38b |
| 100 |
|
| 101 |
-- |
| 102 |
Arthur Zamarin |
| 103 |
arthurzam@g.o |
| 104 |
Gentoo Linux developer (Python, Arch Teams, GURU) |
Archives