On Jul 22, 2010, at 2:29 PM, Charlie Brady wrote: > > On Thu, 22 Jul 2010, Karanbir Singh wrote: > >> On 07/22/2010 04:25 AM, Gordon Messmer wrote: >>> That could be. I'm not sure which specific things you're referring to. >>> I vaguely recall frequent volunteers to engage in the >>> build/test/release process met with the pronouncement that CentOS's team >>> is a meritocracy and that people will be allowed in as they prove their >> >> Yes, thats about right. The idea of testing stuff within CentOS has a >> very finite end point. With very few exceptions the only people trying >> to get onto the testing team are people looking for early access. There >> have only ever been a small number of people who actually do anything. I >> would love, more than anything else at this time, to have a large and >> productive testing team - but one that actually does something. > > I don't think the problem here is either the size or the idleness of the > test team. What are the steps involved in > building/validating/testing/releasing security updates? I don't know. > Which steps have been completed and which steps are still to be done. I > don't know. Is the bottleneck the testing team? I don't think so. > In general, everyone doesn't really know what is contained in a "security" fix. The details of a "security" fix are typically only summarized, and one is expected to be able to infer from the patch the relevance to the underlying security issue. The harder (general, true for all distros, not just CentOS) is the release engineering involved. For starters -- because its "security" related -- the priority and timeliness are important. However security fixes are invariably "out-of-band" in the sense that there's never enough time and resources to run through a full QA integration cycle. So the release engineering involves shrewd/savvy guessing that nothing else is gonna be broken by distributing the patch. There's the further procedural risk of mis-building. Keeping build systems in perfect condition gets trickier and trickier as distros (like CentOS5) age. All security patches need to be applied as well as the original release. Any new package build relies on having a build system sufficiently close to be able to rebuild reliably. While of the above may seem obvious, the specific points are 1) there are no steps and there is no process. Instead its savvy guesses and spot checks and triple checks. 2) the bottleneck _IS_ in some sense the testing team, who are expected to achieve the pretense of "perfection" in spite of the "out-of-band" QA procedures involved. You really start to think hard and carefully before claiming WORKSFORME when your reputation is at stake. Its embarassing when some silly error has to be re-released or re-re-re-re-released to achieve the desired "security" fix goal. > What we do know are that Tru has been unavailable for various reasons and > Karanbir is "supposed to be covering for him (and doing a bit of a crap > job at the moment)". These things happen, and I don't wish to attach > personal blame. But I think it is also useful to acknowledge that these > are the reasons for the non-released packages, rather than talk about > testing resources or opportunities for people to contribute to the wiki. > > As I stated earlier, I think there is systematic process issue that the > CentOS project should address. I'm not sure whether you are saying that > there isn't a problem, or that the problem exists but is not solveable. I > don't think either response is appropriate. Wouldn't it be more useful to > admit that there is a problem, and discuss exactly what needs to be done > to solve it? > There are several levels of problem, but the hardest problem is figgering How much "out-of-band" QA is sufficient? That comes only from experience. There are other elements -- no different for any process that involves humans -- of vacations and moves and attention interrupts and more. But "security" fixes are usually only spot checked that indeed, the security issue is "fixed", and the release process is assumed to be just cookie-cutter gear-turning which it often is not, because older distros like RHEL5 get increasingly more complex to maintain reliably as they age. > [I'm trying to be constructive here, so please don't be defensive. Russ > can vouch for me. I don't just wish to be spoonfed, and I do know what it > is like to ask for help and receive little. I just don't see that as the > problem here.] > I hope my comments don't qualify as "spoonfeeding", they certainly weren't intended as such. Security "fixes" are a hard problem to solve in _ALL_ distros, not just CentOS. 73 de Jeff