1 |
As I am sure everyone is aware by now, stabilisation requests on many |
2 |
architectures take a long time to be actioned. There are many factors |
3 |
contributing to this, but today I'd like to address three specific |
4 |
problems that unnecessarily delay developers actioning those requests.: |
5 |
|
6 |
1. There's no easy way to pick atoms out of a stabilisation bug. |
7 |
Currently, atoms can appear, in a varying formations, in multiple |
8 |
locations: in the bug title, spread across multiple comments, in an |
9 |
attachment, [...]. |
10 |
|
11 |
2. There's no way to determine if a stabilisation request is valid (will |
12 |
pass repoman) until someone actually tries it. |
13 |
|
14 |
3. There's no easy way to identify the level of testing required for any |
15 |
given request. |
16 |
|
17 |
To address this, I am proposing some changes to Bugzilla, some |
18 |
automation, and some improved tools. |
19 |
|
20 |
|
21 |
Bugzilla changes |
22 |
================ |
23 |
|
24 |
I'd like to introduce two new fields: |
25 |
|
26 |
1. "Runtime testing required" - a drop-down list with three values: |
27 |
* (unset) - the default. The stabilising developer will use |
28 |
their best judgement as to what testing is required |
29 |
* Yes - the maintainer is specifically requesting runtime testing |
30 |
* No - the maintainer is happy to stabilise with only a build |
31 |
test (for example, trivial revision bumps, libraries with good test |
32 |
coverage, or otherwise at the maintainer's discretion) |
33 |
|
34 |
2. "Atoms to stabilise" - a textarea containing a list of fully |
35 |
qualified atoms. Each atom may optionally be followed by a |
36 |
whitespace-delimited list of architectures for which that atom should be |
37 |
stabilised. If an atom is not followed by any list of architectures, it |
38 |
is assumed it should be stabilised for all architectures CC'd on the bug. |
39 |
|
40 |
Example atom list from a bug with amd64, arm, and x86 in CC: |
41 |
|
42 |
=app-foo/bar-1.2.3 # will be stabilised on amd64, arm, and x86 |
43 |
=app-foo/baz-2.3.4 amd64 x86 # will be stabilised on only amd64 and x86 |
44 |
|
45 |
I'd also like to introduce a flag called "repoman-tested". This will be |
46 |
used identify stabilisation requests that have been automatically |
47 |
repoman checked by a bot (described below). |
48 |
|
49 |
To prevent cluttering the Bugzilla interface, I suggest resurrecting the |
50 |
"Stabilisation" component and having these new fields appear only for |
51 |
bugs filed there and in "Security: Vulnerabilities" (so not to disrupt |
52 |
the security team's workflow). |
53 |
|
54 |
|
55 |
Automation |
56 |
========== |
57 |
|
58 |
It's easy to forget to check that all the required dependencies are in |
59 |
stable before filing a stabilisation test, but this wastes the actioning |
60 |
developer's time. I have prepared a bot that repoman checks the list of |
61 |
atoms and flags the bug appropriately. This allows easy filtering out of |
62 |
broken requests. |
63 |
|
64 |
|
65 |
Improved tools |
66 |
============== |
67 |
|
68 |
To support the above, I am also preparing some tools to streamline the |
69 |
process further: |
70 |
|
71 |
* A script to, given a bug, produce an architecture-specific list of |
72 |
atoms ready to feed into package.accept_keywords / emerge |
73 |
|
74 |
* An updated version of app-portage/tatt (allowing easy testing of USE |
75 |
flag combinations, reverse dependencies, committing keyword changes etc.) |
76 |
|
77 |
* Your idea here |
78 |
|
79 |
|
80 |
Too long; didn't read |
81 |
===================== |
82 |
|
83 |
We add a new box to Bugzilla to hold atoms on stabilisation request bugs |
84 |
so it's easy to extract programmatically. |
85 |
|
86 |
We add a new box to Bugzilla to indicate if a stabilisation request |
87 |
requires runtime testing or not to better focus effort. |
88 |
|
89 |
If your stabilisation request is invalid a bot will let you know and it |
90 |
will be easy to skip your request until you fix it. |
91 |
|
92 |
|
93 |
This will also help pave the way for future enhancements such as |
94 |
triggering automated build and QA tests so that the human only has to do |
95 |
runtime testing. |
96 |
|
97 |
Thoughts? |