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