On Wed, 2005-09-07 at 11:39 -0400, Daniel Veillard wrote: > On Wed, Sep 07, 2005 at 10:53:25AM -0400, Jeremy Katz wrote: > > > Delaying the release of FC5 raises the risk of > > > decoupling from our user base and people who test bleeding edge, with a > > > HEAD that is so hard to install and get running people who want to test > > > new stuff have an easier upgrade path by installing Ubuntu (and maybe > > > openSuse) than trying to get Rawhide going. I am afraid the current state > > > of Rawhide just means silent exodus of the people who really help building > > > the distro. The fact that the installer has been broken for months in my > > > experience is a very significant threat, and increase the risk associated > > > to delaying FC5 to an extend we didn't anticipated. > > > > Actually, we delayed FC5 partially so this work *COULD* happen. The > > installer needs to be mostly working by the time test1 comes out. And > > some of the changes just need more time than the usual 2.5 months > > between a release and test1. > > As was pointed out the longuer between releases, the more new bits > being tested in parrallel during those tests releases and the harder to > stabilize. So let's stop GNOME development for a month and just work on the kernel. Then we'll flip-flop :) > > I do think that we want to consider having four test releases with the > > first one earlier than the current schedule. That will help to avoid > > some of the problems you're afraid of. > > Instead of 9 month cooking it and then a succession of test releases > then release what about test release after each substancial change > e.g.: > FC5-test-kernel-2.6.13 > FC5-test-x.org-modularized Except that all of the upstream projects have their own schedules and if we hold off on doing things with them during _their_ development cycles, then we end up in the same bad state. > i.e. instead of pushing everything back to the end, have snapshot test > releases, where some incremental testing gets done by the people not brave > enough to go though a real rawhide testing. They would not have to have the > same amount of testing than for final test release but would allow a larger > community feedback on what is likely to break on them. I do that myself at > a smaller scale when I push bits in my projects and I know there is a > possibility of breakage, it works fine if people get the information they > need to test something specific. We are already doing this to some extent > but involving just the specific packages update (kernel or modularized X11), > being able to quickly cook up a small downloadable test release may be useful > too. Doing the small downloadable test release is a significant amount of work. eg, for modular X, a number of anaconda changes will be needed. Similar for gtk+ 2.8 and cairo. > Would that increase the distro team work significantly ? I think it > would increase early feedback (good), maybe it could even be offloaded to > volunteers if the recipe to make and test basic releases is opened. > > 2 cents, trying to bring something positive from an unlucky experience... I think the way to go here is really yum repositories with targeted package testing. ISOs really are a *lot* harder. Things might be getting easier in the future for doing something like this. But, it's all dependent on the anaconda changes that are breaking a lot for now :) Jeremy -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx http://www.redhat.com/mailman/listinfo/fedora-devel-list
