To semi-rolling or not to semi-rolling, that is the question...

[Toshio Kuratomi]

On Fri, Mar 05, 2010 at 08:52:56AM +0100, Hans de Goede wrote:
> > Make rawhide consumable as a semi-rolling release itself.
> 
> We already have this it is called early branching of the next release. I
> would fully agree with you if it were not for the early branching
> feature, which means we effectively already have such a release, except
> the first 2 months or so after a release, at which time rawhide
> tends to be very volatile in general (*), so a stabilized rawhide would
> pretty much boil down to the latest release anyways.
> 
This is something I've been toying with in my mind myself.  I like the idea
of using it better than using rawhide for the same reasons that Till Mass
mentions in his email.  I haven't been able to completely satisfy myself on
two points though:

1) This new tree is supposedly leading towards a new release.  As such,
there are other pressures on it than simply being a consumable tree.  (For
instance, updates will be frozen for periods in this tree as alpha and beta
are spun; the freezes lead to a huge number of updates on release day).  How
disruptive these pieces are to using this tree as a consumable product in
its own right is the worry.  However, we haven't yet run a full release of
no-frozen-rawhide so we don't know precisely how annoying the problems would
be or how easily solvable.

2) The new tree is not consumable all the time because there are times when
it does not exist.  As you also mention, there is the period right after
release when the unrelease tree does not exist.  There's only F-current
(which would be taking less updates under a policy that anticipates people
who want semi-rolling to be consuming the F-current+1 tree) and rawhide
(which, as you say, is very volatile at this time.)  In fact, this is
probably the time period in which a semi-rolling tree would be most useful
to people (as at other times of the cycle, maintainer laziness would make
rawhide closer to the current+1 tree and therefore more consumable)  Do you
have any ideas on what we could do here?

-Toshio
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
Url : http://lists.fedoraproject.org/pipermail/devel/attachments/20100305/d3fd1d39/attachment.bin