On Fri, Dec 12, 2008 at 11:17 AM, Kevin Martin <kevintm@xxxxxxxxxxxxx> wrote: > 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: No apologize necessary... I'm just laying it out for you. This is a community effort. If we need to enhance update QA, the solution is going to have to involve more community contributors working on the problem. There is no way around it. But some thought has already gone into the structure being used. Users may not be aware of Koji, but its there, and maintainers and developers use it to cut update packages. I use koji's scratch ability, I don't throw updates out to the repos without testing them for myself. But I also don't have to deal with serious security vulnerabilities for the packages that I maintain...so I don't have the same pressures that more critical component maintainers have so I'm not going to go out of my way to pontificate on their workflow. > > I could be convinced to help implement more "automated testing" if I > understood what that meant. It's going to mean writing code which can be run to test specific functionality for a given package. > > 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? A mistake was made with this package. No one is denying that. But the unanswered question is, other than deliberately refusing to allow security updates to be rushed how do we reduce the risk of that mistake from happening again? How important is security to you? Are you fine with holding up ALL security updates for a few days to offset the risk of this sort of thing from happening again? I don't think I could support that. And since I'm not a security expert I can't say I would do a good job of vetting individual security updates to know whether or not they need to be rushed or not. And even that vetting would be an additional delay for all security updates. > 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! Its a community project. If we want better QA we have to step up and be a part of that effort. I have updates-testing enabled on my day-to-day work laptop. I turn on package caching in yum so I can revert to an older update something goes very very wrong. This allows me to test and give me a safety net to work from for most breakage scenarios. Worst case rpm no longer works and I have to use rescue mode from media to back out the rpm update. I purge the cache based on package age. I update the laptop either at the beginning of the day or at the end, depending on my schedule to give me time to revert breakage and report if I notice any. That is what I do. I do a bad job of noticing breakage however as my day-to-day workload involves very few things beyond python scripts, a terminal, ssh and a web browser. > > 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. I'm all ears. What are specific procedure recommendations which would have prevented this mistake? It was a valid security update and it was mistakenly pushed to stable instead of testing. What could have been done differently? And how would that policy change impact all the other valid time-critical security updates? -jef -- fedora-list mailing list fedora-list@xxxxxxxxxx To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
