On Wednesday, September 22, 2010, 6:19:28 PM, Jesse wrote:
On 09/22/2010 04:07 AM, Adam Williamson wrote:
> On Wed, 2010-09-22 at 10:24 +0100, Richard W.M. Jones wrote:
>
>> This is reasonably easy to fix: we should do some testing and withhold
>> packages from Rawhide if they don't pass some basic sanity checks
>> (eg. does it boot, can an X server be started).
>
> That's basically the proven testers process, which at present is running
> around capacity trying to cover three releases (two current stable, plus
> Branched). I'm really not sure we could manage another release,
> especially one like Rawhide where people have a right to expect updates
> to land quickly.
I think the idea is to apply an AutoQA filter between the builds and
showing up in rawhide, not applying a bunch of human tester filters and
bodhi.
Add a separate rawhide-testing repo as a staging area for changes
(equivalent to updates-testing in a branched release).
- Use autoqu to run basic tests and dependency checks.
- Use a subset of the controls for branched releases.
The focus should be that once dependencies and any package-provide
tests are good things can quickly and automatically move into
rawhide.
Suggestions re controls:
Make the delay for automatic promotion short (say 2 days delay instead
of a week). Let bad karma hold back bad updates, but make promotion
easier than for a branched release. Don't tie up proventester
resources. Allow developers to push directly to rawhide if the autoqa
tests pass - require FES override otherwise.
In other words, create a sane system that parallels that used by
branched releases.
Al