On Wed, Oct 10, 2018, 14:46 Jim Jagielski <j...@jagunet.com> wrote: > > On Oct 10, 2018, at 3:37 PM, William A Rowe Jr <wr...@rowe-clan.net> > wrote: > > On Wed, Oct 10, 2018, 14:28 Jim Jagielski <j...@jagunet.com> wrote: > >> >> On Oct 10, 2018, at 3:01 PM, William A Rowe Jr <wr...@rowe-clan.net> >> wrote: >> >> On Wed, Oct 10, 2018 at 1:45 PM Jim Jagielski <j...@jagunet.com> wrote: >> >>> I thought the whole intent for a quick 2.4.36 was for TLSv1.3 support. >>> >>> If that's not ready for prime time, then why a release?? >>> >> >> AIUI, it isn't that httpd isn't ready for release, or even httpd-test >> framework. >> Until all the upstream CPAN modules behave reasonably with openssl 1.1.1 >> we will continue to see odd test results. >> >> The question is How Comfortable Are We That TLSv1.3 Support Is Production >> Ready? >> > "We" answer that question by voting on a release candidate.
This release seems very, very rushed to me. It seems strange that for >> someone who balks against releasing s/w that hasn't been sufficiently >> tested, or could cause regressions, and that the sole reason for this >> particular release is TLSv1.3 support which seems insufficiently tested, >> you are uncharacteristic cool with all this. >> > > You elided the other half of my answer, you might want to read the entire > comment. > > If we can exercise the same discipline with 2.4.37 that we showed with > 2.4.35, then instead of producing a string of releases with a string of > regressions, we still come out ahead for all users. > > > You wrote: > It was my hope we would push this out as 2.5.1-alpha, as now synced > with 2.4.x branch, and let the eager early adopters help us uncover any > unforeseen issues. Think we have a handle on, and have addressed > the anticipated issues. > > So "eager early adopters" are OK with modules *you* wish to push out, even > if they aren't quite ready, but NOT OK with modules and features others > want, even if they also agree that they 'have a handle on, and have > addressed the anticipated issues' > Do you actually remember what an -alpha release was? I know we've thrown all the s&$# against the wall that would stick for the past 8 years, waiting until it was announced to find out how much would slide back on the floor. What I just wrote above is that I think 2.4.36 is premature, but a release for users to test is not. But since all of our discussions of reversioning end up as immature as your silly provocation above, I've been done debating. I haven't said yes or no to 2.4.36, I only started promoting the idea of 2.5 alpha again, and even had a brief hope you supported the idea, before you suggested throwing the contents of trunk en masse back into the maintenance branch 2.4. That's when I checked out of the discussion, no desire to keep beating my head against that brick wall. In other words: would anyone else have suggested adding a major feature > such as this, with somewhat questionable testing as well as it being the > sole reason for said release, you would have complained and dismissed such > explanations as 'eager early adopters' as facetious. I am glad that this is > no longer the case and you have Seen The Light! As long as we can show an > attempt at testing, and convince ourselves we have a "handle on" anything > that might pop up, and addressed any anticipated issues, we can continue > adding new features as we have been and still come out ahead for all users. > Again, this is what I and others have been pushing and promoting for years > so I am again glad that you have finally agreed. > > It's the inconsistency that is bothersome. > I've stated repeatedly that so long as httpd project members remain split on offering a security and defect-fix maintenance branch, and in violent opposition to moving forward with an enhancement 2.next or even 3.0 release, I've checked out from expressing an opinion on the way the project manages the release branch, or the readiness of that branch, and I'll just pay attention to trunk, which is interesting to me. My only recent input was a plea to get out the first regression fix, security and maintenance release out since 2.4.18 or so (looks that we succeeded with .35), support for the proposal to start moving on 2.5.1-alpha from trunk, and an absolute insistence that all RMs observe both the public STATUS as well as our internal security STATUS in preparing and publicizing releases. Other details aren't worth endless debate threads. When a 2.4 release is approved, I'm about to propose the same feature/enhancement freeze for one subversion (so .38 following .37, should the .36 candidate prove not ready yet) to address newly introduced (yet undetected) defects, before we return to the is all pattern of chaotic changes again. Presenting this as 2.5.1-alpha and leveraging our users@ scrutiny still makes more sense to me, and if the changes proved non-disruptive, shipping these as 2.4.x afterwards.
