[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: fedora 7 schedule (was Re: Fedora 7 planing)



Hi,

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:
http://mail.gnome.org/archives/gnome-hackers/2002-June/msg00041.html

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?


Havoc


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]