| |||||||||||||
Why Tie It to a Release Schedule?Why Tie It to a Release Schedule?Posted Nov 8, 2012 16:35 UTC (Thu) by wagerrard (subscriber, #87558)Parent article: Slipping or skipping Fedora 18
Why is the redesign of Anaconda tied to any particular release schedule? Is it imperative that it be included in F18? Is some striking fault in need of correction? Given the short 6-month cycle, are there advantages to allowing an effort like an Anaconda redesign to operate outside the constraints of that cycle's release schedule? Releases would not be held hostage to delays in major efforts like that, and, in the end, it should be less problematic to roll the new bits into a release.
(Log in to post comments)
Why Tie It to a Release Schedule? Posted Nov 8, 2012 21:11 UTC (Thu) by smoogen (subscriber, #97) [Link]
Because the installer depends on a lot of upstream utilities (python version, kernel version, dracut interfaces, glibc changes, etc) it can never just be moved from version to version without a lot of work. Just keeping track of all the special cases of hardware X, bios Y needs this can take up a lot of time also. So the team can either work on old anaconda or a new one.. and the release must have a working installer so it is either going to be the team doing old like usual or new.
This has been a problem from RHL 6 timeframe.. (and before with the older installer). And like most coding problems you can't throw more developers at it. The people who know how to write a new code base are the ones who would be the ones who would have to maintain the old. [And while everyone is welcome to help out.. it would seem that only a very very very small number have volunteered to do so.]
|
|||||||||||||