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

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.


More information about the devel mailing list