On Aug 11, 2016 1:59 PM, "Rainer Jung" <[email protected]> wrote: > > Am 11.08.2016 um 19:53 schrieb William A Rowe Jr: > >> On Aug 10, 2016 4:58 PM, <[email protected] <mailto:[email protected]>> wrote: >>> >>> >>> Author: rjung >>> Date: Wed Aug 10 21:58:47 2016 >>> New Revision: 1755882 >>> >>> URL: http://svn.apache.org/viewvc?rev=1755882&view=rev >>> Log: >>> Silence more "defined but not used" compiler >>> warnings when building against OpenSSL 0.9.8a. >> >> >> Just a quick observation... After trunk is in sync with 2.4.x on OpenSSL >> 1.1.0 support, can we rip out all pre-1.0.1 code? None of that has been >> supported for some time, in some cases for a very long time. > > > I suppose you mean "rip out from trunk".
Yes. > I'd say let's wait a bit so that fixes due to the huge OpenSSL 1.1.0 compat patch in 2.4.x would be easier to backport and then when everything looks good we can rip out support for OpenSSL < 1.0.2 from trunk. We can also check, how much code that would actually remove. Please consider that 1.0.1 is not unsupported until Dec 31st. That strikes me as premature. When and if the project chooses to ship trunk as a release, something I'm very dubious of at this point, in that month we should reevaluate if 1.0.1 is still applicable and perhaps eliminate those cases/exceptions. But 0.9.7 is not. 0.9.8 is far in the rear view mirror. Very few ever adopted the 1.0.0 release for a variety of reasons. 1.0.1 will stick with us for a long while, even as the OpenSSL abandons it at year end. Everything else, from the trunk perspective, is ancient history. > I also plan to review the mod_ssl differences between 2.4.x and trunk and investigate whether there's stuff that would be easy to backport (and worth it), so that code drift is reduced. It would be easier to do that before the rip-out. > > I'll post separately about the OpenSSL 1.1.0 compat patch once it is ready for review. Currently running the test suite looks quite good. I guess I need to find a way to cut the 1300 lines patch into smaller parts which are easier to review. Reviewing all the 35 or so commits to the branch I created is probably not the best way to do it. Thank you for all of your attention and diligence to this rework. I, and most of us here, sincerely appreciate your efforts. Cheers, Bill
