Testing test releases: do not update

[Mike A. Harris]

On Fri, 27 Feb 2004, Robert P. J. Day wrote:

>Date: Fri, 27 Feb 2004 03:29:54 -0500 (EST)
>From: Robert P. J. Day <rpjday at mindspring.com>
>To: fedora-test-list at redhat.com
>Content-Type: TEXT/PLAIN; charset=US-ASCII
>List-Id: For testers of Fedora Core development releases
>    <fedora-test-list.redhat.com>
>Subject: Re: Testing test releases: do not update
>
>
>
>On Fri, 27 Feb 2004, Mike A. Harris wrote:
>
>> Rawhide *is* the updates repository.  What is in rawhide *IS*
>> what will be in the final OS.
>
>does this mean that a package showing up in rawhide represents a
>*commitment* that it will be in the next release (be it test or official)?
>surely, there must be the option that, if such a package represents a
>complete disaster, RH will back off and revert back to an older, working 
>release, no?  but if the newer version was already in rawhide for a while, 
>folks will undoubtedly have downloaded it and begun testing it, and 
>because of the update process, they're stuck with that newer version until 
>the next snapshot.  is that about right?  does this have any sub-optimal
>consequences?  just curious.

Sorry, I was a bit unclear there.  To clarify:

What is in rawhide at any given point in time, is what is 
currently planned to go into the final OS release, unless 
something occurs that requires either updating the package with 
bug fixes, or updating it to a new upstream release, or 
downgrading the package or removing it entirely, possibly 
replacing it with an alternate package with similar or identical 
functionality.

The idea, is that what is in rawhide is "current plan to ship" 
and if people aren't testing it, they aren't testing what is in 
the current plans.  The plans may of course change, and the code 
could as I mention above, be downgraded/upgraded/removed/replaced.

>also, i still think there's a conflict with rawhide being simultaneously:
>
>1) the proposed next release, and
>2) the source of really cool, new, bleeding edge stuff
>
>it's not clear that these two categories represent the same
>thing.  are they supposed to?

The definition of rawhide is "our current internal tree,
consisting of the latest bits including new bleeding edge stuff,
bug fixes, code-in-testing, and other stuff that is planned to go
into the next OS release, which are subject to change at a
date in the future should the need arise".  Or something to that 
effect.


>what happens to rawhide as RH gets close to an official release
>and imposes a feature freeze?  at that point, there should only
>be bug fixes, not new versions of software, right?  but if
>that's the case, does that mean the entire rawhide repo is
>frozen in terms of new releases as well?

Exactly.

>put another way, is rawhide ever allowed to get ahead of what's planned 
>for the next release?

No.  Rawhide is the rolling set of packages that will comprise
the next OS release eventually.  Nothing goes into rawhide unless 
it is destined to be in the final OS release.  So you won't for 
example see Fedora Core 3 development packages going into rawhide 
until after Fedora Core 2 is gold mastered and shipped as an 
official OS release.

As each Fedora Core 2 milestone is reached, feature freezes get 
hit, and code freezes, string freezes, etc.  If you look at the 
target milestones on our website:

http://fedora.redhat.com/participate/schedule/

That outlines what type of changes have to be in the tree by 
which date (barring date slips).  You'll notice that March 12 is 
the current date planned by which any package version updates 
must be in by.  Any package version update that has not been done 
by that date will not get updated unless we've already planned on 
some exceptions, such as the listed GNOME exception.  There are 
sometimes other exceptions as well, but generally we do not 
upgrade package versions beyond that point except for compelling 
reasons.




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