1 |
On Fri, Nov 25, 2016 at 06:41:20AM +1100, Michael Palimaka wrote: |
2 |
> As I am sure everyone is aware by now, stabilisation requests on many |
3 |
> architectures take a long time to be actioned. There are many factors |
4 |
> contributing to this, but today I'd like to address three specific |
5 |
> problems that unnecessarily delay developers actioning those requests.: |
6 |
> |
7 |
> 1. There's no easy way to pick atoms out of a stabilisation bug. |
8 |
> Currently, atoms can appear, in a varying formations, in multiple |
9 |
> locations: in the bug title, spread across multiple comments, in an |
10 |
> attachment, [...]. |
11 |
> |
12 |
> 2. There's no way to determine if a stabilisation request is valid (will |
13 |
> pass repoman) until someone actually tries it. |
14 |
> |
15 |
> 3. There's no easy way to identify the level of testing required for any |
16 |
> given request. |
17 |
> |
18 |
> To address this, I am proposing some changes to Bugzilla, some |
19 |
> automation, and some improved tools. |
20 |
> |
21 |
> |
22 |
> Bugzilla changes |
23 |
> ================ |
24 |
> |
25 |
> I'd like to introduce two new fields: |
26 |
> |
27 |
> 1. "Runtime testing required" - a drop-down list with three values: |
28 |
> * (unset) - the default. The stabilising developer will use |
29 |
> their best judgement as to what testing is required |
30 |
> * Yes - the maintainer is specifically requesting runtime testing |
31 |
> * No - the maintainer is happy to stabilise with only a build |
32 |
> test (for example, trivial revision bumps, libraries with good test |
33 |
> coverage, or otherwise at the maintainer's discretion) |
34 |
> |
35 |
> 2. "Atoms to stabilise" - a textarea containing a list of fully |
36 |
> qualified atoms. Each atom may optionally be followed by a |
37 |
> whitespace-delimited list of architectures for which that atom should be |
38 |
> stabilised. If an atom is not followed by any list of architectures, it |
39 |
> is assumed it should be stabilised for all architectures CC'd on the bug. |
40 |
> |
41 |
> Example atom list from a bug with amd64, arm, and x86 in CC: |
42 |
> |
43 |
> =app-foo/bar-1.2.3 # will be stabilised on amd64, arm, and x86 |
44 |
> =app-foo/baz-2.3.4 amd64 x86 # will be stabilised on only amd64 and x86 |
45 |
> |
46 |
> I'd also like to introduce a flag called "repoman-tested". This will be |
47 |
> used identify stabilisation requests that have been automatically |
48 |
> repoman checked by a bot (described below). |
49 |
> |
50 |
> To prevent cluttering the Bugzilla interface, I suggest resurrecting the |
51 |
> "Stabilisation" component and having these new fields appear only for |
52 |
> bugs filed there and in "Security: Vulnerabilities" (so not to disrupt |
53 |
> the security team's workflow). |
54 |
> |
55 |
> |
56 |
> Automation |
57 |
> ========== |
58 |
> |
59 |
> It's easy to forget to check that all the required dependencies are in |
60 |
> stable before filing a stabilisation test, but this wastes the actioning |
61 |
> developer's time. I have prepared a bot that repoman checks the list of |
62 |
> atoms and flags the bug appropriately. This allows easy filtering out of |
63 |
> broken requests. |
64 |
|
65 |
This part would need to take into account DEPENDS ON in the bug too. |
66 |
When I file my xfce lists I dep on the gnome stable bug since I need |
67 |
the gtk stuff and if that isnt taken into account, repoman would just |
68 |
die. |
69 |
> |
70 |
> Improved tools |
71 |
> ============== |
72 |
> |
73 |
> To support the above, I am also preparing some tools to streamline the |
74 |
> process further: |
75 |
> |
76 |
> * A script to, given a bug, produce an architecture-specific list of |
77 |
> atoms ready to feed into package.accept_keywords / emerge |
78 |
> |
79 |
> * An updated version of app-portage/tatt (allowing easy testing of USE |
80 |
> flag combinations, reverse dependencies, committing keyword changes etc.) |
81 |
> |
82 |
> * Your idea here |
83 |
> |
84 |
> |
85 |
> Too long; didn't read |
86 |
> ===================== |
87 |
> |
88 |
> We add a new box to Bugzilla to hold atoms on stabilisation request bugs |
89 |
> so it's easy to extract programmatically. |
90 |
> |
91 |
> We add a new box to Bugzilla to indicate if a stabilisation request |
92 |
> requires runtime testing or not to better focus effort. |
93 |
> |
94 |
> If your stabilisation request is invalid a bot will let you know and it |
95 |
> will be easy to skip your request until you fix it. |
96 |
> |
97 |
> |
98 |
> This will also help pave the way for future enhancements such as |
99 |
> triggering automated build and QA tests so that the human only has to do |
100 |
> runtime testing. |
101 |
> |
102 |
> Thoughts? |
103 |
|
104 |
Everything here sounds pretty good to me! |
105 |
|
106 |
I just realized there is another rare issue that we may have to take |
107 |
into account. Some sets of packages *must* be stablized in lockstep. For |
108 |
regular sets of packages like eg xfce if you leave off a bunch of the |
109 |
extras its no big deal. |
110 |
Eg for SELinux, the policy packages must all be stabilized all at |
111 |
once because they depend on each other (I think perl is like this too?). |
112 |
|
113 |
We would need a way for maintainers to ask for testing without actually |
114 |
committing. The maintainer can wait till everything is done and commit |
115 |
everything at once himself. Some flag to make the tatt script skip the |
116 |
step would be enough I think. |
117 |
|
118 |
-- Jason |