On 25 April 2014 01:14, Viktor Dukhovni <[email protected]> wrote: > On Thu, Apr 24, 2014 at 04:56:09PM -0700, Quanah Gibson-Mount wrote: > >> >> The problem with this approach are significant requests that have languished >> for years. One such example would be >> <http://rt.openssl.org/Ticket/Display.html?id=1365>, which is 8 years old >> now. The best place to get the fix these days is probably directly from >> Debian (<https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=589520>). > > Perhaps patches that are added in major O/S platforms and are not > fundamentally specific to the platform in question should get a > higher priority. > > * They are in most cases proposed by relatively experienced users, > (the Debian PRNG fiasco aside :-). > > * They have been widely tested by users of said platforms. > > So the easiest approach may be for Debian, RedHat, ... to look > through the various patches they apply and decide which are generally > applicable, and, perhaps not today, but once new processes are more > clearly established, open new tickets clearly re-stating the status > and motivation of the patch, the origin platform and patch maturity. > > Then I would recommend that the OpenSSL team and volunteers look > at these before most other requests.
Yes. This seems like a sensible refinement. I'd suggest though that if a new ticket is raised then we should encourage people to identify the older ticket so that it can be closed off. I have written up the proposed process as a Wiki page. That way we have it captured and as we make refinements we can update it and have a definitive statement of the approach. My first draft version is here: http://wiki.openssl.org/index.php/Defect_and_Feature_Review_Process I have added a "Principles" section at the beginning which outlines my suggestion around tackling defects from newest to oldest, and have added a new one to basically say we can on an ad-hoc basis tackle older defects if someone identifies them as significant. So this now reads: * Start looking at the newest entries in RT first and work backwards in time. This is on the basis that the newest bugs are likely to still be present and most relevant. As we go back in time we will see more and more which are no longer relevant - we will start hitting the law of diminishing returns. * Older entries can be looked at on an ad-hoc basis if a person doing triage identifies them (probably on the basis of some post to the dev list) as being important * Any new RT entries coming in should get the very highest priority. We can only start to make progress if the problem doesn't continue to grow. Matt ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List [email protected] Automated List Manager [email protected]
