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
_______________________________________________
fedora-advisory-board mailing list
fedora-advisory-board@xxxxxxxxxx
http://www.redhat.com/mailman/listinfo/fedora-advisory-board
_______________________________________________
fedora-advisory-board-readonly mailing list
fedora-advisory-board-readonly@xxxxxxxxxx
http://www.redhat.com/mailman/listinfo/fedora-advisory-board-readonly
