On 20/03/11 14:14, Matthew Willsher wrote:
On 20 Mar 2011, at 13:25, Akemi Yagi wrote:
On Sun, Mar 20, 2011 at 1:37 AM, Matthew Willsher<[email protected]> wrote:
Hello,
I've been looking through the fastbugs and errata repos and have notice some
discrepancies with TUV. For example, RHBA-2010:0857. In TUV this is a bug in
the main EL 6 channel. In SL it's in fastbugs.
Also in fastbugs is RHBA-2011:0339. In TUV EL this is in FasTrack.
Again, in fastbugs is RHEA-2010:0932. In TUV this is an enhancement in the main
channel.
This concerns me a little as this seems to mean that SL fastbugs contains
legitimate, production ready bug fixes along with TUVs FasTrack bugs which are
more fixes if you experience a problem type updates that normal wouldn't be
wanted on production systems. Am I understand this correctly?
A similar question was asked on this mailing list and Troy gave a
detailed answer :
http://listserv.fnal.gov/scripts/wa.exe?A2=ind1103&L=scientific-linux-users&T=0&P=7222
Akemi
Thanks for pointing that post out Akemi. My apologies for not check previous
mailing list posts especially when this one was so recent.
However, mu concern that fastbugs contains bug fixes of a potentially lower
quality (FasTrack bug fixes) than other items in that channel still stands. I
can see the need for security fixes to be kept separate from other types give
SL's stated goals and patch model but I'm not convinced by fastbugs containing
everything else including FasTrack items. IMHO, it would be preferable to split
out into two repos - a TUV bugs+enhancements repo and a FasTrack only
equivalent.
Matt
Hi Matt,
What makes you think upstream FasTrack bug fixes are of any lower
quality than any other errata?
I rebuild the upstream FasTrack channel for my own use and for the most
part the fixes are really trivial - some as trivial as fixing
documentation typos. AFAIK, the main reason for upstream separating them
out into a separate channel is so not to unnecessarily burden sysadmins
with trivial updates. In many enterprise environments, all updates must
undergo additional in house testing before they can be deployed and it
makes little sense to push this extra burden unnecessarily. Red Hat
understands this and thus tries to minimise the volume of updates (for
example, compare to Fedora which experiences near constant churn). OTOH,
others want early access to fixes hence the separate FasTrack channel to
meet that need.
The updates in FasTrack almost without exception make it unchanged into
the next update release (point release). If there were any grounds for
lack of quality then that would surely not be the case. The only
exception to this is where security updates are released for a FasTrack
package before the next update release.
Having looked at and rebuilt many packages in FasTrack, I see no
difference in quality compared to the rest of the distribution. I only
see a difference in severity of issue being fixed.
