[Date Prev][Date Next] [Thread Prev][Thread Next]
[Thread Index]
[Date Index]
[Author Index]
Re: Fastrack channels?
- From: inode0 <inode0 gmail com>
- To: "Red Hat Enterprise Linux 4 (Nahant) Discussion List" <nahant-list redhat com>
- Subject: Re: Fastrack channels?
- Date: Mon, 3 Apr 2006 13:38:50 -0500
On 4/3/06, Jay Turner <jkt redhat com> wrote:
> 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.
I really do appreciate the added flexibility this allows and hope that
it might reduce some of the load and other issues when quarterly
updates do come out.
It does aggravate one related cosmetic issue that seems to bother a
lot of users though. If you subscribe to Fastrack but don't update all
the packages from there your system always shows up as out of date.
This happens anyway when you simply can't upgrade base packages for a
variety of other reasons.
Would you consider adding an up2date configuration setting similar to
the skiplist for telling up2date/RHN to simply ignore a specified set
of packages with respect to "up to dateness?"
My users really like seeing blue/white checkmarks by their systems.
John
[Date Prev][Date Next] [Thread Prev][Thread Next]
[Thread Index]
[Date Index]
[Author Index]