Trying to install rawhide: madness and where do we hope to go ?
Jeremy Katz
katzj at redhat.com
Wed Sep 7 17:13:53 UTC 2005
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
More information about the fedora-devel-list
mailing list