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

[Daniel Campbell <zlg@gentoo.org>]

[-- Attachment #1.1: Type: text/plain, Size: 2581 bytes --]

On 07/25/2017 06:22 AM, Rich Freeman wrote:
> On Tue, Jul 25, 2017 at 9:10 AM, Michael Palimaka <kensington@gentoo.org> wrote:
>>
>> The 30 day waiting period is useful for smoking out major upstream bugs,
>> but can't replace stabilisation integration testing. For example,
>> package foobar may build fine in ~arch but fails in stable because it
>> needs a newer libbaz.
>>
> 
> I think this is a good reason why everything should be at least
> build-tested on a stable tree before getting stabilized.  Now, that
> might not be on each arch if it is truly arch-independent (and if
> arches keep the dependencies reasonably in sync).
> 
> This might be a situation where a compromise could exist.  Have some
> kind of flag (in metadata, or maybe the ebuild) that indicates that
> the maintainer believes the package is low-risk to stabilize purely on
> a build test.  Then after 30 days in testing a tinderbox could
> build-test the package and stabilize it automatically.
> 
> If the package is considered at-risk then it goes through manual
> testing, either by the maintainer or an arch team.
> 
> This will also encourage the teams doing testing to actually do more
> testing on the packages that would benefit from it.
> 
> We wouldn't set hard criteria but leave it up to maintainer
> discretion, with a guideline being that past performance is probably a
> good predictor of future results.
> 
This reads like a practical use of both developer time and machine time.
Build testing at a minimum, imo, is necessary if the word "stable" is
going to mean anything for us. So +1.

Since there are bound to be fewer manually tested packages than
automatic "it builds, ship it" packages, I think it would make a bit
more sense to add a "manually test this please" tag to metadata.xml,
rather than expect auto-stabilizers to have additional tags, which will
outnumber the manual packages and inflate the size of the tree (albeit
slightly).

Since maintainers also manage their packages in various ways, could we
extend this to a general <policy> element? Maintainers can specify how
they'd prefer bugs or commits to be done, and an additional element to
indicate hand-testing. This would solve two problems instead of just
one: indicate a package is ready for auto-stabilization, and give a
single, canonical location for a maintainer to put maintenance policy.

Just my 2¢,

~zlg
-- 
Daniel Campbell - Gentoo Developer
OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net
fpr: AE03 9064 AE00 053C 270C  1DE4 6F7A 9091 1EA0 55D6


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]