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<[log in to unmask]>  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.