On 20 Mar 2011, at 14:30, Phil Perry wrote: > On 20/03/11 14:14, Matthew Willsher wrote: >> 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.
http://www.redhat.com/rhn/rhndetails/fastrack/ agrees with you - they are indeed QA'd and production ready. That wasn't so hard for me to Google :/ Isn't the same true for SL users as TUV's users? That they don't want to be burden by the extra updates? Keeping them in with the main stream bugs and enhancements means that SL admins don't have the luxury of that choice. My point of view on this comes from the ideology that SL should stick to the model used by TUV as much as possible, although I do understand the SL target audience may have different goals and that the model used by SL is developed to fit that goal. Would it be true to say that one of the main goals of SL is to reduce administration costs by allowing it's users to change as little as possible once a system is up and running, rather than TUV's approach of a constantly, albeit slowly, moving target? Regards, Matt
