On Thu, 2009-10-22 at 09:50 -0700, Jesse Keating wrote: > Hi all. It has been brought to my attention that my description of my > future vision of rawhide as explained here is much clearer than previous > attempts (including the current "no frozen rawhide" wiki page). So I > felt it prudent to forward it along to the devel list for more eyes to > look upon it and comment if desired. > > Thanks! > > -------- Forwarded Message -------- > From: Jesse Keating <jkeating@xxxxxxxxxx> > Reply-to: fedora-advisory-board@xxxxxxxxxx > To: fedora-advisory-board@xxxxxxxxxx > Subject: Re: "What is the Fedora Project?" > Date: Wed, 21 Oct 2009 18:58:08 -0700 > > On Wed, 2009-10-21 at 20:35 -0400, Paul W. Frields wrote: > > > >I've heard a bit of preliminary rumbling about DSCM-like Rawhides -- a > > > >way for developers to have trees that move at their pace, and are > > > >possibly quite broken from time to time in ways that differ from each > > > >other. If we were able to develop such a scenario, why not also > > > >provide the flipside of this idea -- make the One True Rawhide the > > > >place where we take in changes that don't break the world, while > > > >they're cobbled on in the other trees? Whether this is an extension > > > >of the "KoPeR" idea or something entirely difficult, it merits serious > > > >consideration. > > > > > > I very much like the aspect of the more stable rawhide here. > > > > Jesse Keating brought up some concerns about integration, but aren't > > those concerns something that people would be interested in solving? > > (I'm assuming those people are the wide variety of engineers working > > in the Fedora community who are smarter than I.) > > > > > > So my plans are really funny. I plan to make rawhide more unstable more > of the time, and I plan to make "rawhide" more stable more of the time. > Crazy eh? How can I do this? By splitting "rawhide" in two. > > Rawhide as we know it, /pub/fedora/linux/releases/development/ will > remain "rawhide". We may even change the path to say rawhide, just to > catch things up and well I like keeping mirrors on their toes. Rawhide > will be a repository of developmental and experimental packages. Things > being worked on for the future. It will /not/ be an installable tree, > rather it will just be a repository of packages, to be added on to an > already stable "base", eg you'd install F12, and enable rawhide to test > rawhide. This will significantly lower the complaints that "rawhide > isn't installable". > > The second face of rawhide, will be the "pending release", that is when > it comes time to feature freeze a release, we'll split it away from > rawhide. We'll publish to /pub/fedora/linux/releases/test/13-pending/ > or some such. THIS tree will be installable. It will be composed each > night, and we'll use bodhi to manage updates to this tree. That means > this tree will have it's own "updates testing" where potential freeze > breaks can be tested and commented on by all, but won't risk the base > tree. If testing pans out, it'll get tagged for the release, if not > it'll get thrown away. This tree will spawn 13-Alpha, 13-Beta, the > snapshots in between, and eventually pub/fedora/linux/releases/13. > > Remember that first rawhide? Yeah, it kept going, unfrozen, leaping > toward Fedora 14. You could still install 13-Alpha, or 13-pending, and > enable/update to rawhide to start testing Fedora 14 stuff. So to make this a reality, we need to ensure that whatever is in rawhide has a *>=* ENVR than anything in the other trees. So I assume that when submitting a bodhi update, bodhi would check rawhide and ensure that whatever you were about to submit to 13-pending was <= whatever was in rawhide. Otherwise we'd get into a great big mess of not being able to update to rawhide packages because whatever was in 13-pending was 'newer' than rawhide. Right? We should have this anyway just to help upgradability between distros; bodhi should not allow a package to be added to an update if it's a "newer" ENVR than that same package in any of the "newer" distros. Dan -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
