Jeff Spaleta wrote: > On Fri, Dec 12, 2008 at 5:49 AM, Kevin Martin <kevintm@xxxxxxxxxxxxx> wrote: > >> FWIW, the 3 layer model is used to great effect in everyday business. >> First, there's "testing" where the developers get to play to their >> > > 3 layers.. without referencing rawhide: > Koji scratch builds: > developers and maintainers have access to binaries in Koji and can do > a number of scratch builds as needed before submitting them to the > updates system for general consumption. Maintainers can and do list > Koji urls in bug reports to get pre-release feedback from bug > reporters if its warrented, before even moving to updates-testing. > > > updates-testing: > Where community QA is meant to happen. > How many people have updates-testing enabled? Do you? > > updates: > Stable updates which 'typically' have gone through updates-testing and > gotten feedback. > > > caveat: > Maintainers have the discretion to bypass updates-testing for critical > fixes and security updates. The dbus update was marked as security > update with a valid CVE listing. It was inadvertently pushed to stable > in error bypassing testing. > > I'm not sure what sort of policy change could have prevented this and > yet would not have also significantly impacted the speed at whichl > security updates are made available. Are you willing to have all > security updates held back for a week in updatest-testing to protect > against what happened with dbus? I don't think I can justify that as > a policy initiative. > > The only thing which is going to help prevent what happened with dbus, > is implementing "enough" mandatory automated testing somewhere in the > process that all packages submitted to stable must go through...even > all security tagged updates. Even automated testing has costs, and if > we have "too much" it will also impact the speed at which security > updates can be delivered. > > Are you willing to help implement more automated testing? > > -jef > > It sounds as if I touched a nerve here and, if so, I apologize. I was simply trying to point out an "industry practice" that makes some sense. That being said: I could be convinced to help implement more "automated testing" if I understood what that meant. The argument of getting "critical" and security fixes out in a timely fashion seems valid but it's apparent that, in this case, testing of the "fix" would have gone a long way in preventing the issue at hand from occuring (and should these fixes *really* not be QA'd at all? We see in our software many times where what appears to be a very small "fix" ends up cascading down the line into other problems that need to be "fix"'d. I don't know, and excuse me if this is offensive, if taking the Microsoft stance of rolling out "fixes" without proper testing is a boon to the community.). No, I don't have updates-testing enabled since my only Fedora box is my production laptop that I use for work (and continues to run F8 as a result until F10 is stable) *and* personal use...if this had occured on this laptop I would have been royally f*d! Again, I'm not trying to criticize the work done by the Fedora developers/maintainers et. al. I'm simply saying that, possibly, better procedures may have stopped this from happening in the first place. Kevin -- fedora-list mailing list fedora-list@xxxxxxxxxx To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
