Proposal - "Slow updates" repo

Casey Dahlin cdahlin at redhat.com
Tue Nov 18 18:53:37 UTC 2008


There's been a lot of talk about a stable release lately. Most agree 
that its not what Fedora does best and not something that would be 
natural for us to do. I have a sort of middle-ground proposal that might 
be easy enough to implement that we could try it out.

Currently, when a packager has an update, he runs "make update," and 
bodhi goes and grabs the package out of koji and places it in the next 
mash of the updates-testing repo (Luke, please shout when I start 
getting this wrong). Then, bold subscribers to updates-testing install 
it, check it out, and if two people report in that it didn't eat their 
brane, it goes into the regular updates repo. That slim sanity check 
prevents a whole helluva lot of breakage, but isn't a very broad testing 
of the package.

What I propose is having another repo called updates-slow. Like updates 
testing this repo ships with Fedora but is disabled and hidden by 
default. Interested parties would have to manually enable it, and 
disable the regular updates repo. updates-slow would relate to updates 
in a similar way that updates relates to updates-testing: packages would 
go into it after people getting the general Fedora updates seem to be 
ok. The criteria here would have to be much harder than the two karma 
points it takes to move out of testing, I would suggest the people 
interested in this feature form a group that decides what the entry 
policy should be.

The advantage is that this is fairly cheap to set up. Bodhi would need 
some level of changes (Luke, what do you think?) but there's no 
branching. We're basically just taking the ability which already exists 
in yum to selectively take updates and providing a system to 
collaboratively exploit this mechanism.

Not branching, however, also creates a disadvantage: with no ability to 
create new packages, the slow repo can't take newer fixes without taking 
an entire update. The slow repo must consume updates from Fedora in 
whole packages; they don't have patch-level control over incoming 
changes. Also, the slow repo has to synchronize at release time; you 
can't have a late-F9-with-bits-of-F10 offering (hopefully though the 
base set is the peak of mainline Fedora's QA).

If the people interested in a stability feature are willing to help 
govern and maintain this repo, and help with the bug load (we can't just 
dump bugs against backdated versions directly on the maintainers), then 
it could go a long way to meeting their needs.

Thoughts?

--CJD




More information about the fedora-devel-list mailing list