fedora 7 schedule (was Re: Fedora 7 planing)

[seth vidal]

On Tue, 2006-12-12 at 22:48 -0500, Luis Villa wrote:
> NB: Most of this email will probably seem obvious, since everyone here
> is experienced and intelligent. I offer it on the off chance that it
> isn't obvious, and in the hope that it will spur everyone to ask
> questions and think critically about assumptions Fedora may have
> carried over from RH that should be examined in light of the different
> goals a community project has from an enterprise operating system.
> 
> On 12/12/06, Dave Jones <davej at redhat.com> wrote:
> > On Tue, Dec 12, 2006 at 05:47:47PM -0500, Luis Villa wrote:
> >
> >  > Has Fedora, the community, actively post-mortemed past slips? If so,
> >  > what were the most likely causes of past slips, and what steps are you
> >  > taking to avoid them this time around?
> >
> > I recall at least 2-3 issues last time around.
> >
> > * Xen being horked and taking forever to get working.
> >   Not particularly easy to fix given we're at times dependant upon
> >   an unresponsive upstream.
> 
> So what would the plan be for a similar problem in the FC7 schedule?
> Lets call this 'feature X'. Possible options would be:
> (0) Prevent feature X from going into distro trunk until feature X was
> actually ready-ish, such that there was never risk of delay from
> feature X.
> (1) back feature X out completely, or at least to the FC6 state.
> (2) admit that feature X will not work in FC7.
> (3) delay FC7.
> 
> In my ideal development world, one aims for (0) as much as possible;
> In GNOME, we'd typically do (1); it seems like in FC6 with Zen you
> chose (3).
> 

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.

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?

-sv