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

[Martin Sivak]

Hi,

> If/when the "real work" behind a feature has been done early enough,
> getting from Fedora alpha to final consists of just a few bugfixes

Ah well.. only if everybody else did this so all the dependencies are stable.
In which case you just moved the development freeze to earlier date. No improvement..

> > Basically there should not be any "this cannot be reverted" (there
> > is
> > no such thing really) features. If it is evident before the feature
> > freeze that a given feature would not be ready in time we have to
> > punt
> > it to the next release PERIOD.

Then there will be no possibility of major rewrites ever. Because some
changes just take more than few months to execute and supporting a branch
with very old (anaconda's GUI first commit in git is from 1999) codebase
takes a lot of manpower.

And to use drago's words: We do not have unlimited resources.

When Gnome decides they are not fixing bugs for Gnome2 and put all resources
to fixing Gnome3, you can wait, because most apps still depend on the mostly stable
Gnome2 anyway and the bugs are not show stoppers, merely annoyances.

When we do this in anaconda, you can't just use the older release, because
other components are changing underneath us and the old release will break.

So you will write bugs and RFEs for us to fix in the old branch so you meet your
release deadline and mostly nobody will be testing the new branch.
One release later at the alpha time.. we will get into the same issue of not being ready.

We will take the heat whatever model we choose.

So we have chosen. When this is done, we will have UI which has sane
API and is separated from the other internal components and that will allow
us to maintain the installer and firstboot in much better and easier way.

Martin