fedora 7 schedule (was Re: Fedora 7 planing)

Havoc Pennington hp at redhat.com
Wed Dec 13 15:47:24 UTC 2006


As historical context, when I was proposing the "time-based release" 
thing for GNOME the idea was based on Red Hat Linux, which had a strict 
6-month time-based cycle. Part of my logic was that GNOME was becoming 
more and more like a Linux distribution, in that it was a lot of 
independently-released modules without true central coordination.
Because of this, time-based was the only way to guarantee getting a 
release out; there would never happen to be a time where all the 
upstreams were in sync.

The rules surrounding time-based releases, both as we had them back in 
the Red Hat Linux days and as they are in GNOME today, are designed to 
deal with this. One of the important rules is that anything that goes on 
the to-be-released branch must be basically usable (dogfoodable, within 
a few bugfixes of shippable). For Red Hat Linux we usually phrased this 
rule as "you can't put any beta versions into the tree, only final 
released versions"

The original mail goes into this a bit more:

I was avoiding mention of Red Hat Linux back then since there were some 
political tensions it might have poked, but the idea was based on Red 
Hat Linux processes.

seth vidal wrote:
> Cutting out a couple of the cases b/c I wanted to suggest something that
> sets fedora development apart from gnome development, for example.
> For a big part fedora doesn't control the feature set of the upstream
> package. If two of our guiding principles are: 1. run upstream  and 2.
> run newest versions then we're being pushed ahead by things that are not
> entirely w/i our control.
> In gnome if feature X is not stabilized there's some room to say, "ok,
> not that one, walk it back, we have to release." but fedora is
> hard-pressed to make the same demand of gnome or kde or firefox.
> I'm not saying that we cannot do some amount of damage control but if
> the choice is:
>  1. patch out some feature (and therefore OWN that fork)
>  2. ship the newer, broken one
>  3. ship the older one
> None of those options are terribly good.

Both the GNOME and the historical Red Hat Linux take on this would 
usually be 3, ship the older one. 1 or 4 were only done for 
business-type reasons such as "we really need NPTL for a customer" but 
those reasons are now supposed to be for RHEL, in fact part of the idea 
of Fedora was/is to get rid of them.

3 is the only one that is guaranteed to ship a stable product without 
causing a delay. 1 can also ship stable product without a delay, but 
only if you know you can assign someone to do the work in a finite 
timeframe. If 1 becomes "hope someone patches the feature" then 1 can 
mean delay. 4 almost invariably means delay.

Since some package in the distribution will always be in the "not ready" 
situation, the only way to ship the whole distribution on time is to 
commit to either 3) or a variant of 1/4 in which some specific person is 
tasked with resolving a well-known specific problem in finite time 
sufficiently far in advance.

If you're willing to choose 4) ever, you will almost always be late for 
one reason or another.

> And so the 4th option which no one loves is:
>    4. slip and hope that we can get the newer one fixed.
> Does that sum up a lot of what happens when fedora slips a release?


More information about the fedora-advisory-board mailing list