Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID))

[Tom Lane]

Adam Williamson <awilliam at redhat.com> writes:
> ... Practically speaking, for F18,
> though, I think we just need to soldier on with newUI and get it done as
> best we can. Obviously slipping the schedule by a week again and again
> in response to the latest fire isn't the best way to do things, but
> stepping back and taking a wider view, a release that's a month or two
> behind but with a reasonably solid new anaconda wouldn't be a disaster. 

My concern at this point is exactly that we're "slipping a week at a
time", rather than facing up to the *undeniable fact* that anaconda is
not close to being shippable.  If we don't have a workable contingency
plan, I think the best thing to do would be to start slipping a month at
a time.  And drop the beta-freeze restrictions, until we reach a point
where anaconda actually is beta quality.  Other people have work they
could usefully be getting done, except that they have to jump through
these beta-freeze hoops --- which not incidentally are slowing down
anaconda work too.  It's insane that we are wasting time debating
whether anaconda bugs are release blockers or beta blockers or only NTH,
when any honest evaluation would recognize that the whole thing hasn't
reached alpha quality yet, and *all* those bugs had better get fixed if
we don't want F18 to permanently damage the reputation of Fedora.

You can slip a month (or two) honestly, or you can fritter it away a
week at a time, and ensure that as much of that time is unproductive as
possible.  There is not a third option.  (Brooks' _Mythical_Man-Month_
has useful things to say about this sort of scheduling trap --- anybody
who hasn't read it should.)

			regards, tom lane