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

Stephen John Smoogen smooge at
Wed Oct 31 17:59:23 UTC 2012

On 31 October 2012 11:39, Chris Adams <cmadams at> wrote:
> Once upon a time, Stephen John Smoogen <smooge at> said:
>> This only seems to work for teams or parts that can split their
>> resources over doing 4 releases at one time (really old, current
>> release, new release fixes, next release coding). With stuff like
>> anaconda where the code usually has to get its stuff fixed after
>> everything else has landed.. that makes it a very hard to ever look at
>> next release coding unless it is done in a jarring way.
> That's true in general, but not really for anaconda.  Since there are no
> official update images, once a release is out the door, the anaconda
> team should basically be done with it (especially when there's not much
> point in bug-fixing code that isn't going to ever be released again).

Again.. that is a nice theory but in reality it is not true. Fedora
Intel is not Anaconda's only customer.  Fixes have to go in for other
branches. Fixes have to go in for spins, Fixes have to go in for
downstream customers be it some respin or Red Hat Enterprise Linux.
Fixes need to go in because maybe you won't run into that problem in
the next release and you better fix it now versus pulling that broken
code later. This means that you are not going to be able to stick on
new development until some X date which is going to be at least a
month or 3 before you can really focus on new development.

Honest Fact: 2-3 releases ago I would have been on the "This is crap
why is this happening yet again???". I am not doing so because I took
time out to look at the sausage factory and see what causes these
pile-ups every 2-3 years when an anaconda rewrite has to occur for one
reason or another.

Stephen J Smoogen.
"Don't derail a useful feature for the 99% because you're not in it."
Linus Torvalds
"Years ago my mother used to say to me,... Elwood, you must be oh
so smart or oh so pleasant. Well, for years I was smart. I
recommend pleasant. You may quote me."  —James Stewart as Elwood P. Dowd

More information about the devel mailing list