terminology and the hierarchy of releases

Jay Turner jkt at redhat.com
Mon Feb 9 16:07:25 UTC 2004


On Mon, Feb 09, 2004 at 10:46:25AM -0500, Robert P. J. Day wrote:
> i can conclude that there are four levels of rpms, in order of
> stability and testing:
> 
>   1) base (the actual official release)
>   2) updates (approved)
>   3) proposed updates (a.k.a. updates/testing)
>   4) development (cutting edge)
> 
>   now, first observation -- while numerous people refer to "rawhide",
> there's no mention anywhere on that page that rawhide is in fact
> equivalent to the development stuff.  perhaps a note to that effect on
> that page would be useful.
> 
>   next, if i add an entry for the development repository to my yum.conf
> file, from what seth wrote, i should remove entries for the updates and
> testing repos, right?  does this mean that some rpm in development might
> in fact be an older version of what might be found in updates?  that is,
> a test release might represent backing off from an updated version in
> an earlier release?  or is that hierarchy above supposed to represent
> monotonically non-decreasing version numbers as i go from 1->2->3->4?
> if that's true, then i should be safe leaving in the updates and testing
> entries in /etc/yum.conf, no?

I think the truth lies somewhere in the middle.  According to the way
things have gone for 5 years (not saying they will always go this way, but
5 years is a pretty good sample) the versions of everything down the list
should increase or at least be the same:

base <= updates <= proposed updates <= development

Digging a little deeper, here's what Seth might have been trying to get at
(and if not, he'll probably correct me.)  There could potentially be
conflicts running the updates/proposed updates code along side the
development code.  If nothing else, being subscribed to the proposed
updates and the development channels would mean that any testing on the
proposed stuff would be invalidated (as you wouldn't really be sure if the
failure was the base+updates code, or the bleeding edge development stuff.
So, as a good scientist, probably best to sticking with just one changing
variable.

> 
>   finally, is it really true that the rawhide/development  rpms represent 
> the basis for the next test release?  it would seem to me that anything
> to be included in the next release should represent at least a minimal
> amount of testing and stability, while historically, i remember rawhide
> being used for really bleeding-edge, way-out-there software for which
> there was absolutely no guarantee.
> 
>   IOW, if you look at development as the basis for the next release,
> you'd think there should still be a category beyond even *that* --
> stuff that is still so new and untested that it's not yet being
> considered for the next release.  at least, not at this time.

This is actually one of the topics which came up quite a few times during
planning for how Fedora would be laid out.  We knew there would be times
that we would have to branch Fedora development, where one branch would go
down a path which was incompatible with existing code, and the other branch
would continue with existing development.  In it's short lifetime, we
haven't had to cross this bridge yet with Fedora, and off the top of my
head, I can't think of what would cause us to in the near future, but I'm
sure something will pop up, be it a huge kernel change, new compiler, or
something else which just proves to be too big for a 3 month development
window.

- jkt

-- 
--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*
Jay Turner, QA Technical Lead      jkt at redhat.com             Red Hat, Inc. 

        Reality is merely an illusion, albeit a very persistent one.
                                                   - Albert Einstein





More information about the fedora-test-list mailing list