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
Attachment:
signature.asc
Description: OpenPGP digital signature
-- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
