On 11 April 2014 00:00, Steve Marquess <marqu...@opensslfoundation.com> wrote: > > With the very, very important caveat that I'm not one of the people who > directly carry this burden: > > There is certainly room for improvement in the process by which patches > are reviewed and merged into OpenSSL. For the more straightforward bug > fixes and minor changes it might be useful to have a mechanism where a > patch could be approved by multiple people and then committed to OpenSSL > almost automatically. Obviously this wouldn't work for significant > changes like whole new APIs and infrastructure mods.
I have long been of the view that the current process for reviewing patches is broken. Through no individual's fault there just aren't enough people with commit rights to review the number of patches that get submitted. Many of these patches are really quite straight forward and I think we miss out on a lot. I see lots of patches go by which would have added value (e.g. documentation fixes, minor code fixes etc). If someone has gone to the effort of providing a patch, then they really deserve some kind of response (even if that response is thanks but no thanks). Many patches go by without anyone ever looking at them. I could envisage some kind of triage process where patches are classified into different levels or risk, and dependent on that risk a different level of scrutiny is required. E.g. so a patch providing a documentation tweak is treated differently to a patch providing a big piece of new functionality. I could also imagine a hierarchy of comitters with different levels of sign-off - low risk changes can be comitted by a larger group of people - only high risk changes need to go to the core team. > > The "multiple people" could be a sufficiently large and diverse group of > serious and committed stakeholders, both OpenSSL team members and > others. Volunteers? I see many of the same names appear on this list and on the users list from people who clearly know what they are talking about and have a high degree of skill. I am sure some of those could be persuaded to help out. I of course would be happy to volunteer :-) > > Of course, a process like that wouldn't necessarily prevent future > vulnerabilities like the Debian PRNG issue or the heartbeat bug. Even > gross bugs are only truly obvious in hindsight. > True. And in fact it seems counter-intuitive when faced with a major problem like heartbleed to open up the project to *more* people capable of comitting. The temptation is to "batton-down-the-hatches" and keep new people out. But actually I think by involving more people in the review process we have the opportunity to improve quality through having many-eyes reviewing changes - instead of just a very small number who don't have enough time to spend on it. Matt ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
