On Mon, 2006-04-03 at 11:10 -0500, Daryl Herzmann wrote:
> On Mon, 3 Apr 2006, Jay Turner wrote:
>
> > On Mon, 2006-04-03 at 14:35 +0200, Dirk Gfroerer wrote:
> >> Obviously I missed the announcement for the Fastrack channels in RHN.
> >>
> >> They seem to contain different bug fix Erratas. So are these channels to
> >> which I want to subscribe my production machines?
> >
> > We need to clean up the communication around these channels,
>
> Jay, can you provide us with 1 place this Fastrack channel was announced
> publicly?
I cannot at this point.
>
> > So these are packages which have been through complete QA, are fully
> > tested and we're making available to customers via RHN child channels.
>
> > All packages pushed into the child channel will become part of the
> > follow-on release unless circumstances prevent (serious issues found
> > with the package.)
>
> What does the combination of those two statements say about RedHat's QA?
>
> To rephrase, it means that RedHat will fix problems found in the FastTrack
> channel ASAP, but in the base channel, you will wait 4-5 months.
>
This was certainly not the intent of my statements. We're really trying
to serve two masters any given day here at Red Hat, the people that want
a regular and scheduled update and those that can consume almost as fast
as we can produce. So Red Hat puts out RHEL4-U3 and people start
deploying. Engineering starts working on the code for delivery with
RHEL4-U4 so you see a large influx of new code. We wanted an avenue to
release that new code which wasn't going to destabilize the folks asking
for a regular and scheduled update. Thinking of it as "fix[ing]
problems found in the Fastrack channel ASAP" isn't quite the truth.
We're fixing problems in RHEL and giving the users two options, take it
or leave it. Even better, we're giving the users this option on a case
by case basis (just because you consume sendmail from the Fastrack
channel doesn't mean you have to consume everything else in the channel,
for example.) Since the packages pushed to the Fastrack channel are
fully supported by Red Hat, it's really the best of both worlds. More
strict enterprise organizations can even drink from both fountains by
subscribing test hardware to the Fastrack channels, giving themselves
even more time to evaluate and qualify content destined for the next
update.
> What ever happened to dumping packages in the beta channel?
We will still do that as we get closer to the follow-on release. So
what makes the beta channels different from the Fastrack channels?
Actually quite a bit. Typically the beta channel content hasn't gone
through full-bore QA. In addition, we'll push kernel and toolchain
updates to the beta channel, something we won't provide through the
Fastrack channels. The content of the beta channels is just that,
"beta." The Fastrack channels contain fully-tested, ready for
prime-time packages.
>
> Dirk's original question remains about subscribing his production machine
> to this channel. I have more questions than answers at this point.
You're right, I didn't explicitly answer the question. Guess I assumed
that my response led to the inherent answer. Yes, people can subscribe
their production machines to these channels. Since we aren't pushing
kernel or toolchain updates to Fastrack, users don't have to worry about
3rd party applications breaking. And since these packages are fully
supported, there's essentially no more risk in deploying these packages
as deploying those from the base channel.
- jkt
--
--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*
Jay Turner, QE Manager jkt redhat com Red Hat, Inc.
If A equals success, then the formula is: A = X + Y + Z,
X is work. Y is play. Z is keep your mouth shut. - Albert Einstein
Attachment:
signature.asc
Description: This is a digitally signed message part