beta/rawhide upgrade paths (was: New Kernel - athlon - Mozilla)

[Mike A. Harris]

On Mon, 8 Sep 2003, Jeremy Katz wrote:

>On Mon, 2003-09-08 at 10:47, Axel Thimm wrote:
>> Seriously though I strongly second Alexandre's objection. If you want
>> people to track betas or rawhide at least they should be assured that
>> upgrade paths work. Leave the 20 in there until 2.4.23 or strip the
>> "1." from the revision number.
>> 
>> Yes, rawhide is for breaking things, but please not the versioning :(
>
>This happens regularly during the development cycle.  Always has and
>until people are perfect, there's not much that can be done about it. 
>Just have to strive to have it happen as rarely as possible.
>
>The exact same caveats apply for the RHN channel that have always
>existed for rawhide -- the main difference is that the barrier to entry
>is lower.  

I second this motion.  A few weeks back, the xterm package had a 
slightly different problem which caused upgrades from the 
previous rawhide xterm to fail.

While I received numerous bug reports (and still a few are coming 
in), the broken package which caused the problem was indeed a 
rawhide highly-experimental-do-not-test-this-if-you-can-not 
handle-breakage package, and as such a bit of breakage did occur.  
The very few number of people likely to have hit that problem 
seems to have stopped now that the fix has been available for a 
while, and so no further action is needed.  A small handful of 
people might be left who have the broken xterm package, and will 
hit the problem still.  In a month or two, it wont matter anymore 
at all.

I suspect the kernel problem above will result in the same more 
or less.

Rawhide is raw, expect it to break is the motto.  Don't use/test 
it if you can't handle some amount of breakage like this is my 
advice.


-- 
Mike A. Harris     ftp://people.redhat.com/mharris
OS Systems Engineer - XFree86 maintainer - Red Hat