| 1 |
Hi, |
| 2 |
|
| 3 |
Before I start replying to specific bits, I think it would be reasonable |
| 4 |
to outline the flow of a keywording/stabilization bug. I would split it |
| 5 |
into 4 steps: |
| 6 |
|
| 7 |
S1. Someone (anyone) files a bug requesting it. |
| 8 |
|
| 9 |
S2. Someone (maintainer or OP) prepares a complete list of packages |
| 10 |
(including dependencies). |
| 11 |
|
| 12 |
S3. The maintainers approve (or reject) the request. |
| 13 |
|
| 14 |
S4. The arch teams process the request. |
| 15 |
|
| 16 |
Now, I think all considerations on automation should be from |
| 17 |
the perspective of those steps. |
| 18 |
|
| 19 |
|
| 20 |
On pon, 2017-07-24 at 22:22 +0100, Sergei Trofimovich wrote: |
| 21 |
> TL;DR |
| 22 |
> ----- |
| 23 |
> |
| 24 |
> I see the problem of lagging stable and unstable trees as: |
| 25 |
> |
| 26 |
> 1. lack of automation |
| 27 |
> 2. lack of manpower |
| 28 |
> |
| 29 |
> The PROPOSAL to solve the '1. automation' part is to draft |
| 30 |
> a new GLEP. If there is any interest (I assume there is!) I'll start one. |
| 31 |
> Let's call that fufure 'life of KEYWORDS'. It will cover: |
| 32 |
> |
| 33 |
> - Update on GLEP-40 ("x86 stabilization can do only x86@ team") |
| 34 |
> to allow package maintainers to do ARCH=x86 stabilization. |
| 35 |
> It will be an arch-agnostic way: each arch will have minimal requirements |
| 36 |
> to setup environment suitable for stabilization and keywording: |
| 37 |
> CFLAGS to have, hardware required, whatever else is practical. |
| 38 |
|
| 39 |
I'd dare say arch-specific policies are arch team's business. |
| 40 |
The replacement for GLEP 40 should set some base rules but allow arch |
| 41 |
teams to override them. |
| 42 |
|
| 43 |
I feel like this is going towards 'anybody can do keywording / |
| 44 |
stabilization'. I'd rather not go this route right now, and just let |
| 45 |
arch teams recruit people as they see fit. |
| 46 |
|
| 47 |
- Formalize list of stable arches as such (will be covered by |
| 48 |
> 'arches.desc' GLEP) |
| 49 |
> - Formalize what is a "stable arch". In short: |
| 50 |
> - arch is marked as such in 'arches.desc' |
| 51 |
> - performs most of STABLEREQ/KEYWORDREQ or gives rationale |
| 52 |
> why progress can't be easily done before 90-days timeout |
| 53 |
|
| 54 |
Just to be clear, is this going into your GLEP? I'd prefer if |
| 55 |
the 'arches.desc' GLEP was kept purely technical wrt the file format |
| 56 |
and not covered policies. |
| 57 |
|
| 58 |
Oh, and when you are doing the new GLEP, don't forget to mention |
| 59 |
ALLARCHES. |
| 60 |
|
| 61 |
> |
| 62 |
> - Formalize and automate process of dropping keywords for timed out |
| 63 |
> STABLEREQ/KEYWORDREQ requests. |
| 64 |
> - Automate process of restoring dropped KEYWORDS due to bumps |
| 65 |
> adding new unkeyworded dependencies. repoman already complains |
| 66 |
> about those. What is left is to grab them in batches time to time |
| 67 |
> and handle those as if those were KEYWORDREQ. |
| 68 |
|
| 69 |
This might require making more proactive use of '-foo' keywords (QA |
| 70 |
tools complain about them right now), or some other way of indicating |
| 71 |
'I have tested it and it won't work'. Or at least checking for WONTFIX |
| 72 |
bugs. |
| 73 |
|
| 74 |
> - File more automated STABLEREQs to rely less on lazy maintainers |
| 75 |
> (I am example of lazy maintainer not siling STABLEREQs enough). |
| 76 |
|
| 77 |
What I'm a little worried about is that this would proactively try to |
| 78 |
stabilize package versions that are not suitable for stabilizations, |
| 79 |
e.g. upstream development branch. Without expecting too much guesswork |
| 80 |
on the scripting, I'd say it'd be reasonable enough if it checked for |
| 81 |
WONTFIX bugs to avoid filing the same rejected bug again. |
| 82 |
|
| 83 |
Those are the solution for S1 and maybe partially S2 in my flow above. |
| 84 |
What I'd add for S2: |
| 85 |
|
| 86 |
- make stable bot more proactive on complaining about package lists with |
| 87 |
missing dependencies -- right now it waits for arch teams to be CC-ed; |
| 88 |
given this might require packages from other maintainers, it'd be better |
| 89 |
if it tried investigating earlier (guessing keywords from existing |
| 90 |
package if they are not explicitly given in package list). |
| 91 |
|
| 92 |
> - Formalize which STABLEREQ/KEYWORDREQ can be done automatically |
| 93 |
> by arch teams (or maybe anyone else having the hardware!). |
| 94 |
> In short: anything not marked as "Runtime testing required" |
| 95 |
> on bugzilla and not having any blocker bugs. |
| 96 |
|
| 97 |
And that's S4. I'd focus on leaving it for the arch teams to have |
| 98 |
a final say but the 'runtime testing required' part is reasonable. |
| 99 |
|
| 100 |
|
| 101 |
All that said, I think there's one more important part of tooling we're |
| 102 |
missing right now: reverse mapping of packages into keywording / |
| 103 |
stabilization bugs. In other words, having a package app-foo/bar, I'd |
| 104 |
like to know if its keywording or stabilization has been requested |
| 105 |
anywhere. In other words, if I should include it in my bug, or just link |
| 106 |
to some other bug, or... |
| 107 |
|
| 108 |
-- |
| 109 |
Best regards, |
| 110 |
Michał Górny |
Archives