On 31 October 2012 10:56, Toshio Kuratomi <a.badger@xxxxxxxxx> wrote: > > There's a mismatch between this practice and the theory of how we > develop Fedora. When there is a mismatch from practice and theory... theory usually needs to change :). > https://fedoraproject.org/wiki/No_Frozen_Rawhide_Proposal#Problem_Space > """ > We also tell folks that a development cycle of Fedora starts from the branch > point of the release to be and goes all the way to the release of the next > release > """ > > The theory of developing Fedora is that development starts when we branch > rawhide from Fedora-Next. For the F18 cycle, this was January or February > 2012. So the theory is that currently, there's been about 9 months for the > development of Anaconda for F18. There were 6-7 months up to Feature > Freeze when your feature was supposed to be implemented. 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. Historically I don't think any installer rewrite has hit schedule or not caused a looooong delay in a release no matter which team has done it (and there have been multiple ones who have tried to not repeat the mistakes from the last team.) -- 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 -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
