Fedora "backports" repo? (Was Re: PostgreSQL 9 for F14?)
Al Dunsmuir
al.dunsmuir at sympatico.ca
Wed Sep 22 14:14:46 UTC 2010
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
More information about the devel
mailing list