Proposal - "Slow updates" repo

Douglas E. Warner silfreed at silfreed.net
Tue Nov 18 18:57:22 UTC 2008


Casey Dahlin wrote:
> 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?

This almost runs into EPEL's agenda, and on the flip side there are people 
that would like to see EPEL's updates come in a little more frequently. 
Perhaps this 3-repo structure would work well for both groups ("testing", 
"normal", "stable").

-Doug


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: OpenPGP digital signature
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081118/0ec78c4d/attachment.sig>


More information about the fedora-devel-list mailing list