Re: [gentoo-project] Call for agenda items - Council meeting 2016-08-14

[Michael Orlitzky <mjo@gentoo.org>]

On 08/04/2016 12:24 PM, William Hubbs wrote:
> 
> We can allow maintainers to stabilize new versions of certain types of
>  packages on all arches where there is a previous version of the package stable
>  without filing stable requests. This would take a significant load off
>  of the arch teams.
> 
> For packages that do not fit the first group, we could require stable
> requests, but allow maintainers to stabilize the new versions after a
> timeout (I would propose 30 days).
> 
> What do folks think?
> 

This is a good idea; there's a lot of low-hanging fruit here. We could
write up a fairly restrictive list of exceptions and still accomplish a
lot of good.

For example, we've had an exception floating around for a while that
says that maintainers can stabilize their own x86/amd64 packages. That's
assuming they have the hardware, run a stable system themselves, and do
the testing. This sounds reasonable to me -- as the maintainer, I'm
likely to do a better job of testing a package than an arch tester will.
For certain things like web/database servers, I'm using these things in
production for weeks, and the additional build test performed by the
arch team isn't going to add any new information.

Can we at least agree on that exception? Let's codify it in

  https://bugs.gentoo.org/show_bug.cgi?id=510198

and move on from there.

Assuming we go through with that exception, here's another one to
consider: if a package would otherwise be stabilized ALLARCHES, then the
maintainer can perform the stabilization on all arches himself under
those same prior assumptions (he can test, etc). There's no point in
making 8 different people test a new version of some PHP package that
only changed pure PHP code.

Another exception would be for maintainer-needed packages. If there's a
revision that only fixes a bug, we should be able to get it stabilized
and remove the old version even though there's no maintainer.

I would like to add an exception for metadata changes, too, but honestly
I don't trust people to use it wisely. I shouldn't have to bug the arch
teams if I add a second LICENSE and revbump... maybe if this exception
is worded strongly-enough it could do more good than harm.

What I don't want to see is us changing the meaning of "stable" (cf.
making a "D" a passing grade). We should never have maintainers doing
stabilization of C programs on architectures they don't run. I'm only in
favor of exceptions that speed things up without reducing the quality of
the stable tree. This is met by the exceptions I've outlined above, if I
really am doing more thorough testing than the arch teams, or if I have
truly made a harmless metadata change.

In any case, we should still have to wait a minimum of 30 days before
moving a package stable (modulo security issues).