Jeff Spaleta wrote: > On Fri, Dec 12, 2008 at 1:03 PM, Anne Wilson <annew@xxxxxxx> wrote: > >> How often has this happened? In the real scheme of things, what percentage of >> packages have caused problems like this? I'm not denying the problems that >> some people have had, but is there, perhaps, some over-reaction? >> > > How often has what happened? An accidental push to stable meant for > testing? I don't think we could get an accurate count on that. > > We could get an accurate count on the number of times a request > directly into stable has been made.. as an upper bound on our > potential exposure to this problem...but we couldn't infer intent very > easily. We could probably break it out and get security and > non-security pushes. I myself pushed a non-security update directly > to stable this week, to fix a dep problem caused by someone else > pushing an updated library to stable without going through > updates-testing. Was I wrong in doing that? I short-circuited my > normal QA practises to make sure users could get that library update > installed which preceeded my package update. Once we allow any > package to go directly to stable, it can a cascade effect for any > packages which depend on it. > > Also keep in mind that every legitimate security update which does not > go to updates-testing presents a similar breakage risk because it > short-circuiting a QA process for the sake of rushing the security fix > to users. > > -jef > > FWIW I have been in the security arena for some time and any security patch that hasn't been vetted somehow beforehand has to be considered a security risk in and of itself. While fixing one risk who knows what may be introduced if the patch isn't tested...could open up a more severe hole than what was being patched. In good programming practices there's NO reason to not go thru the proper SDLC to make sure that something isn't going to cause more problems than not. I understand that mistakes are made; we've all made mistakes and will make many more before we're done. But having and following guidelines for testing, qa, and then production and making sure that the production environment is COMPLETELY cutoff from the testing area (ie: patches MUST be released from QA as testing can't even see production) will make sure to keep, in this case, this type of issue from cropping up. Everybody in the Fedora development community has the best intentions in mind, I'm sure, and lord knows there wouldn't be a Fedora without the hard work of ALL of the community members and I, for one, am thankful for all of that hard work. Fortunately, this was a fairly minor annoyance in the scheme of all things Fedora, but it could have been so much more had it been some other application/service/etc. 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
