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