Re: [gentoo-dev] [RFC] Future of gentoo's stable and unstable trees: what are your thoughts?

["Michał Górny" <mgorny@gentoo.org>]

[-- Attachment #1: Type: text/plain, Size: 4495 bytes --]

Hi,

Before I start replying to specific bits, I think it would be reasonable
to outline the flow of a keywording/stabilization bug. I would split it
into 4 steps:

S1. Someone (anyone) files a bug requesting it.

S2. Someone (maintainer or OP) prepares a complete list of packages
(including dependencies).

S3. The maintainers approve (or reject) the request.

S4. The arch teams process the request.

Now, I think all considerations on automation should be from
the perspective of those steps.


On pon, 2017-07-24 at 22:22 +0100, Sergei Trofimovich wrote:
> TL;DR
> -----
> 
> I see the problem of lagging stable and unstable trees as:
> 
> 1. lack of automation
> 2. lack of manpower
> 
> The PROPOSAL to solve the '1. automation' part is to draft
> a new GLEP. If there is any interest (I assume there is!) I'll start one.
> Let's call that fufure 'life of KEYWORDS'. It will cover:
> 
> - Update on GLEP-40 ("x86 stabilization can do only x86@ team")
>   to allow package maintainers to do ARCH=x86 stabilization.
>   It will be an arch-agnostic way: each arch will have minimal requirements
>   to setup environment suitable for stabilization and keywording:
>   CFLAGS to have, hardware required, whatever else is practical.

I'd dare say arch-specific policies are arch team's business.
The replacement for GLEP 40 should set some base rules but allow arch
teams to override them.

I feel like this is going towards 'anybody can do keywording /
stabilization'. I'd rather not go this route right now, and just let
arch teams recruit people as they see fit.

- Formalize list of stable arches as such (will be covered by
>   'arches.desc' GLEP)
> - Formalize what is a "stable arch". In short:
>   - arch is marked as such in 'arches.desc'
>   - performs most of STABLEREQ/KEYWORDREQ or gives rationale
>     why progress can't be easily done before 90-days timeout

Just to be clear, is this going into your GLEP? I'd prefer if
the 'arches.desc' GLEP was kept purely technical wrt the file format
and not covered policies.

Oh, and when you are doing the new GLEP, don't forget to mention
ALLARCHES.

> 
> - Formalize and automate process of dropping keywords for timed out
>   STABLEREQ/KEYWORDREQ requests.
> - Automate process of restoring dropped KEYWORDS due to bumps
>   adding new unkeyworded dependencies. repoman already complains
>   about those. What is left is to grab them in batches time to time
>   and handle those as if those were KEYWORDREQ.

This might require making more proactive use of '-foo' keywords (QA
tools complain about them right now), or some other way of indicating
'I have tested it and it won't work'. Or at least checking for WONTFIX
bugs.

> - File more automated STABLEREQs to rely less on lazy maintainers
>   (I am example of lazy maintainer not siling STABLEREQs enough).

What I'm a little worried about is that this would proactively try to
stabilize package versions that are not suitable for stabilizations,
e.g. upstream development branch. Without expecting too much guesswork
on the scripting, I'd say it'd be reasonable enough if it checked for
WONTFIX bugs to avoid filing the same rejected bug again.

Those are the solution for S1 and maybe partially S2 in my flow above.
What I'd add for S2:

- make stable bot more proactive on complaining about package lists with
missing dependencies -- right now it waits for arch teams to be CC-ed;
given this might require packages from other maintainers, it'd be better
if it tried investigating earlier (guessing keywords from existing
package if they are not explicitly given in package list).

> - Formalize which STABLEREQ/KEYWORDREQ can be done automatically
>   by arch teams (or maybe anyone else having the hardware!).
>   In short: anything not marked as "Runtime testing required"
>   on bugzilla and not having any blocker bugs.

And that's S4. I'd focus on leaving it for the arch teams to have
a final say but the 'runtime testing required' part is reasonable.


All that said, I think there's one more important part of tooling we're
missing right now: reverse mapping of packages into keywording /
stabilization bugs. In other words, having a package app-foo/bar, I'd
like to know if its keywording or stabilization has been requested
anywhere. In other words, if I should include it in my bug, or just link
to some other bug, or...

-- 
Best regards,
Michał Górny

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 988 bytes --]