On Tue, Jul 25, 2017 at 9:10 AM, Michael Palimaka <kensing...@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. -- Rich
