Talk:No Frozen Rawhide Proposal


 * User:Bruno: Can we get the release version names to match the appropriate release. So that instead of a version-release of 11.93-1 We'd use 12-0.raw.1 or the like.
 * User:jkeating: It's possible, but we'd have to explore what all consumes the version-release and what those consumers expect so that we don't badly break something's expectations. This feels beyond the scope of this proposal though, feel free to make a new one.
 * User:Bruno:With this getting approved using 12/Everything, having fedora-release use 12 as the version at the time that directory is created is more useful.
 * User:Stijn: would like this as well, currently I have to special case some things in private code to determine 11.9x -> 12


 * markmc The "only make images for pending release tree" could have been a proposal in its own right. Almost sounds like installer images should be built separately from the tree and new images should get pulled in only once they're fairly stable.
 * User:jkeating: It could, but if I can lump it in here, I will (:  The idea is that often people complain that rawhide is broken for installs, when anaconda just isn't ready for people to be trying installs.  Instead people should be starting from a previous known good install point (snapshot, previous GA) and yum upgrade to the rawhide package repo.
 * amacater As someone mirroring Fedora, I'd quite like a smooth transition. When 11 was released, that was another ???GB rather than flicking over a label. I know about hardlink - but Debian doesn't provide it :)
 * User:jkeating You shouldn't have to use the hardlink app. If you rsync with -H rsync will preserve the hardlinks it finds on the mirror, where we have most hardlinkable things hardlinked.
 * I want to suggest rather than trying to figure out the idioms used to refer to the 'development' branch going to release and 'rawhide' we just do one thing very simply. As soon as F-X is out the door, we branch for F-X+1. We then number it in the fedora-release package as X.99.xx where xx are the numbers to differentiate it from any other version (or insert your own numbering scheme here.) Once we go golden, we flip from X.99.xx to X+1. Composing test builds off of that should be relatively simple, because we're just composing a standard Fedora release, albeit one we don't call 'finished' or 'stable'.  Furthermore, if a package maintainer anticipates doing something fancy, the maintainer can put in a request (ahead of time) that the branch be taken from the F-X branch rather than the 'rawhide' branch. This way if the package is not nearly stable enough in rawhide, the maintainer can choose to use the stable F-X branch version instead and carry it forward. &#91;&#91;User:ynemoy&#124;ynemoy&#93;&#93; 19:41, 7 July 2009 (UTC)


 * HansdeGoede jwrdegoede About do we only generate install images for the release tree, no please, atleast before the freeze we also want install images for rawhide itself.

What happens at release time?
The proposal did a very good job of explaining a potential mirror layout, but there's a rather sticky issue here. What becomes of the Everything repo? For example:


 * Branch for F12
 * Everything becomes what's in dist-f12 right now
 * Updates go into -testing
 * Updates move to "stable"

Does moving to stable mean moving to dist-f12 and replacing what's currently in the Everything tree, thus creating the same cohesiveness of a release that we have today, or does it move into -updates? --Jstanley 04:09, 22 July 2009 (UTC)

Answer
User:jkeating Good point, I'll update the page itself, but answer here as well.

When bodhi moves something to stable, it would tag it in dist-f12, and a cron job would re-create the Everything/ tree from dist-f12, so you'd have a cohesive release like we have today. Once we enter release candidate phase for the final release, things pushed to "stable" would actually go into the updates/ dir rather than the Everything tree.

What do we call the pending release tree?
There is no question: it must be called "Chewtoy." --stickster 20:02, 27 July 2009 (UTC)