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@xxxxxxxxxx> 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 _______________________________________________ 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