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

Adam Williamson awilliam at
Tue Oct 30 18:45:02 UTC 2012

On Tue, 2012-10-30 at 19:32 +0100, Gianluca Sforna wrote:

> I don't know if it's impossible to revert to the F17 anaconda at this
> time, however it is clear that F18 is going to be the longest release
> cycle we had in 9 years and somehow we need to avoid this in the
> future.

It's not impossible, well, nothing is impossible, but at this point it's
almost certainly more of a disruption than just plowing on with newui.

It's worth noting quite a lot of the early issues in this cycle -
particularly during Alpha - weren't actually much to do with newui; they
were more to do with changes in dracut which affected anaconda. oldui
wasn't fixed for that, so if were to try and switch back to oldui at
this point, we'd have to go through the whole process of adjusting the
code for the changes to dracut again, quite apart from any other issues.

I think there are some larger issues to do with the Fedora dev cycle and
the feature process that could stand discussion and improvement on the
basis of the experience we've had with F18 so far, for sure. It would be
nice to avoid excessive negativity in doing so, though...I think
throughout everyone has tried their best. 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. 

In a way I think the fact that various groups - QA, anaconda team, FESCo
- have all more or less agreed that we need to ensure decent quality in
the new installer even at the cost of schedule slips is a positive
result of the process; it's dangerous to posit counterfactuals, but I
suspect there are points in Fedora's history where we would have just
more or less stuck to the schedule and kicked out a final release on
time but with a really incomplete new anaconda. Whatever lessons we
learn from this release...I'd like them to be more about how we can
achieve major change with acceptable quality even if that means some
more flexibility about the release cycle, rather than starting from the
assumption that whatever we do, the goal is to stick closer to a fixed
short schedule.
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | adamwfedora

More information about the devel mailing list