--On April 25, 2014 at 12:08:08 AM +0100 Matt Caswell <fr...@baggins.org>
wrote:
I would suggest the following process to do as Ben has requested:
1) We 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 I
suspect we'll see more and more which are no longer relevant - we will
start hitting the law of diminishing returns.
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>).
Note it also has dupes/related:
<http://rt.openssl.org/Ticket/Display.html?id=1832>
<http://rt.openssl.org/Ticket/Display.html?id=2051>
<http://rt.openssl.org/Ticket/Display.html?id=2069>
I've been patching my own openssl build with the ipv6 support for s_client
for a few years now, as we have IPv6 only clients where it is necessary for
debugging purposes. There are likely other extremely useful fixes that
also have gone nowhere for nearly a decade that would provide immediate
pluses to have them committed.
2) 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.
This may induce people to file more duplicates to get older issues
addressed, causing additional work overhead.
--Quanah
--
Quanah Gibson-Mount
Server Architect
Zimbra, Inc
--------------------
Zimbra :: the leader in open source messaging and collaboration
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager majord...@openssl.org
