Once upon a time, Stephen John Smoogen <smooge@xxxxxxxxx> 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). I think part of the problem was that there was an accepted feature for newUI that just punted a bunch of things (such as upgrades and text mode) to F19, and then later (like at Alpha time) people said "wait, we can't do that". IIRC the upgrade code had not been written at Alpha (at least per the original schedule); even though upgrades are not part of the Alpha test matrix, that should have failed as not being at or near feature complete. A lot more thought should have gone into the feature before it was accepted. The initial code needed to be ready (or very close) at F17 branch so it could have landed in rawhide (with install images being built regularly for testing). The list of required functionality for F18 should have been reviewed better, at which point it should have been recognized that it wasn't all going to happen for the original F18 schedule. At that point, the schedule should have been adjusted significantly (maybe another 9 month cycle instead of 6 month), which would have let _all_ of Fedora benefit (with proper planning). IMHO at this point, the schedule should be adjusted for another month (at least, maybe two), and drop the Beta freeze until the re-scheduled time hits. I'm afraid that week-at-a-time slips (with everything else frozen) are going to lead to rushed code, and that often leads to significant problems down the road (bugs as well as poor design choices). -- Chris Adams <cmadams@xxxxxxxxxx> Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
