[Discussion] Limit the scope of 2.4.x patches until 2.4.next is released?

[William A Rowe Jr <wr...@rowe-clan.net>]

Like my beg for getting us to the 2.4.35 release tag, I'd like to propose
we keep patches to branches/2.4.x/ generally within the scope of
straightening out the remaining quirks related to the OpenSSL 1.1.1 API and
library behavior changes (and similar corrections for any alternate library
implementations such as LibreSSL or BoringSSL.)

This isn't a vote per se... just an ask whether we collectively want to
defer all potentially disruptive changes for a release following 2.4.next.
We can certainly resume with that next release on an expedited basis,
within a month or few (as opposed to waiting 6 months as has been typical.)

It appears that dropping in OpenSSL 1.1.1 into a previously working httpd
built against 1.1.0 is not the "plug and play" replacement that the OpenSSL
team originally envisioned, and deliberately building any previous release
of httpd against 1.1.1 is similarly broken.

Thoughts? Other concerns?

Re: [Discussion] Limit the scope of 2.4.x patches until 2.4.next is released?

[William A Rowe Jr <wr...@rowe-clan.net>]

On Thu, Oct 18, 2018 at 4:56 AM Rainer Jung <ra...@kippdata.de> wrote:

> - The other one goes back to the other big refactoring which allowed to
> use SSLProxy* directives in <Proxy> containers, first released in 2.4.32
> this year. It fixes a missing config merge (very small patch). This is
> not related to the OpenSSL 1.1.1 changes but is a small patch fixing a
> regression introduced a few months ago. I think it could go into 2.4.37,
> but would understand a more restricted approach.
>

I agree that reverting any now discovered/resolved regression falls under
the idea of a maintenance release scope, even one more narrowed to
"don't break the release 2x in a row" narrower scope.

Re: [Discussion] Limit the scope of 2.4.x patches until 2.4.next is released?

[Rainer Jung <ra...@kippdata.de>]

Am 15.10.2018 um 16:10 schrieb William A Rowe Jr:
> Like my beg for getting us to the 2.4.35 release tag, I'd like to 
> propose we keep patches to branches/2.4.x/ generally within the scope of 
> straightening out the remaining quirks related to the OpenSSL 1.1.1 API 
> and library behavior changes (and similar corrections for any alternate 
> library implementations such as LibreSSL or BoringSSL.)
> 
> This isn't a vote per se... just an ask whether we collectively want to 
> defer all potentially disruptive changes for a release following 
> 2.4.next. We can certainly resume with that next release on an expedited 
> basis, within a month or few (as opposed to waiting 6 months as has been 
> typical.)
> 
> It appears that dropping in OpenSSL 1.1.1 into a previously working 
> httpd built against 1.1.0 is not the "plug and play" replacement that 
> the OpenSSL team originally envisioned, and deliberately building any 
> previous release of httpd against 1.1.1 is similarly broken.
> 
> Thoughts? Other concerns?

I think everyone is aiming for a mostly riskfree 2.4.next. Apart from 
the already committed mod_ssl change to unbreak h2 with OpenSSL 1.1.1, 
two further mod_ssl backports popped up:

- One is r1828793, prevents crashes for certain configs and is directly 
related to the refactoring done for OpenSSL 1.1.1 support (but does 
happen for TLS < 1.3). I guess this clearly goes into the "straightening 
out the remaining quirks related to the OpenSSL 1.1.1 API" category.

- The other one goes back to the other big refactoring which allowed to 
use SSLProxy* directives in <Proxy> containers, first released in 2.4.32 
this year. It fixes a missing config merge (very small patch). This is 
not related to the OpenSSL 1.1.1 changes but is a small patch fixing a 
regression introduced a few months ago. I think it could go into 2.4.37, 
but would understand a more restricted approach.

Regards,

Rainer

Re: [Discussion] Limit the scope of 2.4.x patches until 2.4.next is released?

[Daniel Ruggeri <dr...@primary.net>]

I like the idea. It took a bit of ruminating to get there, but the thought of shipping new features in odds and fixes/stabilizations in evens (or something along those lines) feels comfortable. I would personally prefer a semver release style where we burn minors often-ish, but haven't been able to comment on Eric's document yet to socialize the thoughts. This is a good compromise in the meantime.

Of course... an important part of making that work is clarifying and documenting the practice with our user community. The other part is having RMs ready/willing to do their thing more frequently. Our unpredictable and often long release cycle could cause features/fixes to get "locked up" in the branch if we don't have a conduit to get those bits to the community. I'm willing to commit cycles there, but my hope is that the automation reduces the barrier to entry for an RM and we can add to the list of ready volunteers. Indeed, I was encouraging jchampion at ACNA to toss his hat in the ring as an RM... here's to hoping :-)
-- 
Daniel Ruggeri

On October 15, 2018 9:10:13 AM CDT, William A Rowe Jr <wr...@rowe-clan.net> wrote:
>Like my beg for getting us to the 2.4.35 release tag, I'd like to
>propose
>we keep patches to branches/2.4.x/ generally within the scope of
>straightening out the remaining quirks related to the OpenSSL 1.1.1 API
>and
>library behavior changes (and similar corrections for any alternate
>library
>implementations such as LibreSSL or BoringSSL.)
>
>This isn't a vote per se... just an ask whether we collectively want to
>defer all potentially disruptive changes for a release following
>2.4.next.
>We can certainly resume with that next release on an expedited basis,
>within a month or few (as opposed to waiting 6 months as has been
>typical.)
>
>It appears that dropping in OpenSSL 1.1.1 into a previously working
>httpd
>built against 1.1.0 is not the "plug and play" replacement that the
>OpenSSL
>team originally envisioned, and deliberately building any previous
>release
>of httpd against 1.1.1 is similarly broken.
>
>Thoughts? Other concerns?

Re: [Discussion] Limit the scope of 2.4.x patches until 2.4.next is released?

[Gregg Smith <gl...@gknw.net>]

On 10/15/2018 7:10 AM, William A Rowe Jr wrote:
> Like my beg for getting us to the 2.4.35 release tag, I'd like to propose
> we keep patches to branches/2.4.x/ generally within the scope of
> straightening out the remaining quirks related to the OpenSSL 1.1.1 API and
> library behavior changes (and similar corrections for any alternate library
> implementations such as LibreSSL or BoringSSL.)
> 
> This isn't a vote per se... just an ask whether we collectively want to
> defer all potentially disruptive changes for a release following 2.4.next.
> We can certainly resume with that next release on an expedited basis,
> within a month or few (as opposed to waiting 6 months as has been typical.)
> 
> It appears that dropping in OpenSSL 1.1.1 into a previously working httpd
> built against 1.1.0 is not the "plug and play" replacement that the OpenSSL
> team originally envisioned, and deliberately building any previous release
> of httpd against 1.1.1 is similarly broken.
> 
> Thoughts? Other concerns?
> 
I'm in favor of the idea.