The future of "rawhide" (was [Fwd: Re: "What is the Fedora Project?"])

[Dan Williams]

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 at redhat.com>
> Reply-to: fedora-advisory-board at redhat.com
> To: fedora-advisory-board at redhat.com
> 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