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(a)redhat.com Red Hat, Inc.
Reality is merely an illusion, albeit a very persistent one.
- Albert Einstein