Gentoo Archives: gentoo-dev

From: Arthur Zamarin <arthurzam@g.o>
To: gentoo-dev@l.g.o
Subject: [gentoo-dev] [RFC] Change the stabilization request flows
Date: Sat, 23 Apr 2022 09:26:08
1 Hi All!
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.
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.
22 --------------------------------
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).
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.
44 --------------------------------
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.
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.
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.
60 --------------------------------
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".
75 --------------------------------
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
90 --------------------------------
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.
97 [1]
98 [2]
101 --
102 Arthur Zamarin
103 arthurzam@g.o
104 Gentoo Linux developer (Python, Arch Teams, GURU)


File name MIME type
OpenPGP_signature.asc application/pgp-signature


Subject Author
Re: [gentoo-dev] [RFC] Change the stabilization request flows Ulrich Mueller <ulm@g.o>