William Hooper wrote: Red Hat is part of a number of non-public groups that discus and fix security issues. Releasing an update into testing before the issue was made public would be irresponsible. --- Any discussion of the handling security issues is always going to be hampered by embargos on sensitive security information. Right now, the frustration the community is feeling with gaim could very well be the result of an ongoing sensitive security issue, associated with the patch. This of course is just speculation on my part. No one who actually knows would be able to comment. And as a a general rule... a 'no comment' comment is still a comment. Vendor-sec and other security related groups membership is going to be a thorn in the side of Fedora long term, if community developers start maintaining pieces of core. It's not clear those developers will ever be allowed to see the vendor-sec notices.... http://www.fedora.us/wiki/VendorSec But that being said.... there is certainly room for improvement with regard to how the security update process is being handled with Fedora. Instead of focusing on gaim in this discussion (which could have complicated vendor-sec issues associated with the patch). I'd prefer to try to look at older security issues, that should be less complicated to discuss. the httpd update, that took 3 weeks, i think might be a better example to look at objectively to understand where any process problems might exist...and ways the community can supplement Red Hat's efforts to solve the problems. The key question of course with regard to the httpd update is what was the real reason the httpd update for fc1 was 3 weeks late? was it a manpower constraint inside Red Hat? was it a technical issue? was it a prioritization issue, in that rolling the update for fedora was considered a low priority compared to non-security related tasks by management or the packager? Looking at the changelog for the httpd update for fc1, and looking at the build date for the package in rpm -qi httpd. The information available seems to suggest this package was actually built in Novemeber. Why it didn't get published till January seems to indicate a process problem and not necessarily a low prioritization to build security updates for fedora core. The httpd package was built..it just didn't make it out as a released update in a timely manner. In fact...it was announced as a test update in Novemeber. http://www.redhat.com/archives/fedora-test-list/2003-November/msg00814. html So technically...a package was available for fedora before it was available at all for rhl9. If anything...there was a break down in moving packages from testing to released. No one is going to argue there aren't problems with how 'testing' is being used. Policy around how things move into and out of testing is not codified, and at this point i think every fedora core developer is making a best effort attempt to use it appropriately...but there's isn't a clear mandate or guideline on how 'testing' is suppose to be used. The concept of the testing branch is new, and its ill-defined. Having httpd sit in testing for that long indicates there needs to be more guidance and policy with regard to how testing is supposed to be used. Moving away from the specific example of httpd, i want to say that in general I see the problems with how 'testing' updates are being released as a symptom of larger scale lack of policy and guidelines for the Fedora development/maintenance process. I personally think its only going to get worse before it gets better. Right now gafton is making getting the CVS repository and the associated contributors paperwork in place so community can start contributing code in some way. Once this tool is in place. the issues of guidelines and communication on how to do things is going to become more more pressing and much harder to make headway on. Right now, Fedora Core developers are Red Hat employees, working in a culture of close-knit internal communication where processes and instructions aren't written down and are instead a sort of word-of- mouth, seat-of-your-pants oral history. This sort of communication culture, might work just fine in small/medium sized companies...where people stick around for the paycheck and learn the day-to-day process over a period of time by watching and emulation others, and being overseen by 'managers.' So instead of a clean written process, with clear written guidelines, there is a long indoctrination period where new employees learn by watching what other people are currently doing. This communication culture breaks down when brand new processes developed and quickly implemented, like the 'testing' repo idea. Since there is no oral history or tradition to follow, everyone is sort of floundering around not really knowing how to use the new process appropriately. This oral history communication process also breaks down, when you have a large influx of new people, and you can't make enough time to mentor them by having them try to follow along watching how the current employees do things. And that breakdown is only going to get worse...when the new people..aren't employees...but are instead volunteers...because volunteers will not be as tied into the internal communication channels as employees are. Volunteers are by and large going to need more mentoring than new employees....and are by and large not going to be willing to wait as long dealing with political overhead to make an impact. It's one thing to twiddle your thumbs while earning a pay check...its quite another to twiddle your thumbs waiting to be told as a volunteer how to contribute to the process. -jef
Attachment:
signature.asc
Description: This is a digitally signed message part
