Re: TLSv1.3 supprt for 2.4.x?

[Stefan Eissing]

> Am 10.09.2018 um 10:59 schrieb Joe Orton :
> 
> On Wed, Sep 05, 2018 at 01:36:06PM +0200, Stefan Eissing wrote:
>> A member of the OpenSSL project gave me a "go ahead" and we now have branch: 
>> 
>> https://svn.apache.org/repos/asf/httpd/httpd/branches/tlsv1.3-for-2.4.x
>> 
>> as a copy of 2.4.x with 
>> 1827912,1827924,1827992,1828222,1828720,1828723,1833588,1833589,1839920,1839946
>>  merged in. If was not a clean merge as some feature from trunk are not 
>> present in 2.4.x, so peer review/test is definitely desired.
> 
> Awesome, thank you Stefan!
> 
> Comparing to what I produced for Fedora, I had a few extra revisions 
> backported (and also missed some of the later ones you caught):
> 
> http://svn.apache.org/viewvc?view=revision&revision=1828220
> - I think this is merged in the branch slightly differently?

I think this overlaps with a subsequent change of SSL_HAVE_PROTOCOL_TLSV1_3 vs. 
SSL_OP_NO_TLSv1_3? Feel free to fix this as you think it's best.

> http://svn.apache.org/viewvc?view=revision&revision=1828790
> http://svn.apache.org/viewvc?view=revision&revision=1828791
> http://svn.apache.org/viewvc?view=revision&revision=1828792
> - I think these should be merged too?

Just done. Thanks!

> 
> I will do some testing now.
> 
> Regards, Joe

Re: TLSv1.3 supprt for 2.4.x?

[Joe Orton]

On Tue, Sep 11, 2018 at 10:42:02AM +0200, Stefan Eissing wrote:
> > Am 10.09.2018 um 10:59 schrieb Joe Orton :
> > http://svn.apache.org/viewvc?view=revision&revision=1828220
> > - I think this is merged in the branch slightly differently?
> 
> I think this overlaps with a subsequent change of SSL_HAVE_PROTOCOL_TLSV1_3 
> vs. SSL_OP_NO_TLSv1_3? Feel free to fix this as you think it's best.

Probably just need to mark it merged, ignore this for now.

> > http://svn.apache.org/viewvc?view=revision&revision=1828790
> > http://svn.apache.org/viewvc?view=revision&revision=1828791
> > http://svn.apache.org/viewvc?view=revision&revision=1828792
> > - I think these should be merged too?
> 
> Just done. Thanks!

Thanks a lot.  

Does anybody have successful test results with post-handshake auth?  I'm 
testing against Fedora's OpenSSL 1.1.1pre9 which has merged the changes 
for https://github.com/openssl/openssl/issues/6933

I'm not able to get a successful PHA exchange, even with a client which 
explicitly enables PHA.  It seems like the test suite will be broken 
until the Perl stack is patched to enable PHA somehow, which is a 
massive headache AFAICT.

Without the SSL_peek(ssl, peekbuf, 0) after SSL_do_handshake(), OpenSSL 
is sending the CertificateRequest to the client but doesn't wait to read 
the response.  With the SSL_peek() call I think it successfully 
completes the "handshake" (and gets the cert) but then hangs waiting for 
app_data which is never coming, and eventually times out.  Anybody got 
better results?

Regards, Joe

Re: 2.4.35 in Sept?

[Jim Jagielski]

If there is still interest, there are a handful of useful backports in STATUS 
that could use review, testing and voting :-)

> On Aug 29, 2018, at 10:10 AM, Jim Jagielski  wrote:
> 
> Looking to maybe do an interim release in Sept...
> 
> Comments? Feedback?

Re: TLSv1.3 supprt for 2.4.x?

[Yann Ylavic]

On Tue, Sep 11, 2018 at 12:13 PM Joe Orton  wrote:
>
> Does anybody have successful test results with post-handshake auth?  I'm
> testing against Fedora's OpenSSL 1.1.1pre9 which has merged the changes
> for https://github.com/openssl/openssl/issues/6933

Just tried trunk+openssl-1.1.1pre9 (SSLProtocol TLSv1.3 and
SSLVerifyClient require), with both firefox and s_client (w/ and w/o
-enable_pha) and can't reproduce the hang.

What's your client tooling?

Regards,
Yann.

Re: TLSv1.3 supprt for 2.4.x?

[Joe Orton]

On Tue, Sep 11, 2018 at 03:39:42PM +0200, Yann Ylavic wrote:
> On Tue, Sep 11, 2018 at 12:13 PM Joe Orton  wrote:
> >
> > Does anybody have successful test results with post-handshake auth?  I'm
> > testing against Fedora's OpenSSL 1.1.1pre9 which has merged the changes
> > for https://github.com/openssl/openssl/issues/6933
> 
> Just tried trunk+openssl-1.1.1pre9 (SSLProtocol TLSv1.3 and
> SSLVerifyClient require), with both firefox and s_client (w/ and w/o
> -enable_pha) and can't reproduce the hang.

Interesting.  I will test with trunk next then.

> What's your client tooling?

Perl/OpenSSL stack, e.g. running t/ssl/basicauth.t from the test suite 
is sufficient to trigger this for me.

Speakers needed for Apache DC Roadshow

[Rich Bowen]

We need your help to make the Apache Washington DC Roadshow on Dec 4th a 
success.


What do we need most? Speakers!

We're bringing a unique DC flavor to this event by mixing Open Source 
Software with talks about Apache projects as well as OSS CyberSecurity, 
OSS in Government and and OSS Career advice.


Please take a look at: http://www.apachecon.com/usroadshow18/

(Note: You are receiving this message because you are subscribed to one 
or more mailing lists at The Apache Software Foundation.)


Rich, for the ApacheCon Planners

--
rbo...@apache.org
http://apachecon.com
@ApacheCon

Re: svn commit: r1840585 - in /httpd/httpd/trunk: docs/log-message-tags/next-number modules/ssl/ssl_engine_kernel.c

[Yann Ylavic]

On Tue, Sep 11, 2018 at 6:01 PM  wrote:
>
> Author: jorton
> Date: Tue Sep 11 16:01:47 2018
> New Revision: 1840585
>
> URL: http://svn.apache.org/viewvc?rev=1840585&view=rev
> Log:
> * modules/ssl/ssl_engine_kernel.c (ssl_hook_Access_modern): Fail with
>   403 if SSL_verify_client_post_handshake() fails, e.g. when the
>   TLS/1.3 client didn't send the Post-Handshake Authentication
>   extension.

There also seems to be some subtilities between SSL_VERIFY_CLIENT_ONCE
(which we use in ssl_hook_Access_modern) and
SSL_VERIFY_POST_HANDSHAKES (another openssl flag related to PHA). I'm
not sure to understand the docs for now...

Both seem to be mutually exclusive (though it's not really stated in
the doc), and possibly we don't use the right one since we call
SSL_verify_client_post_handshake() explicitely. On the other hand
SSL_VERIFY_POST_HANDSHAKES might depend on the client being PHA aware
(and/or advertised?), and if so should we detect it on the server side
to use SSL_VERIFY_POST_HANDSHAKES for the handshake?

I'm asking, should you have more insight on those flags...

Re: svn commit: r1840585 - in /httpd/httpd/trunk: docs/log-message-tags/next-number modules/ssl/ssl_engine_kernel.c

[Joe Orton]

On Tue, Sep 11, 2018 at 06:35:17PM +0200, Yann Ylavic wrote:
> On Tue, Sep 11, 2018 at 6:01 PM  wrote:
> >
> > Author: jorton
> > Date: Tue Sep 11 16:01:47 2018
> > New Revision: 1840585
> >
> > URL: http://svn.apache.org/viewvc?rev=1840585&view=rev
> > Log:
> > * modules/ssl/ssl_engine_kernel.c (ssl_hook_Access_modern): Fail with
> >   403 if SSL_verify_client_post_handshake() fails, e.g. when the
> >   TLS/1.3 client didn't send the Post-Handshake Authentication
> >   extension.
> 
> There also seems to be some subtilities between SSL_VERIFY_CLIENT_ONCE
> (which we use in ssl_hook_Access_modern) and
> SSL_VERIFY_POST_HANDSHAKES (another openssl flag related to PHA). I'm
> not sure to understand the docs for now...

Uh, I missed that. I'm not sure why _VERIFY_CLIENT_*ONCE* is set there 
rather than just _VERIFY_CLIENT... Stefan?  This should restrict PHA to 
once per connection, maybe that is sensible, not sure.

> Both seem to be mutually exclusive (though it's not really stated in
> the doc), and possibly we don't use the right one since we call
> SSL_verify_client_post_handshake() explicitely. On the other hand
> SSL_VERIFY_POST_HANDSHAKES might depend on the client being PHA aware
> (and/or advertised?), and if so should we detect it on the server side
> to use SSL_VERIFY_POST_HANDSHAKES for the handshake?
> 
> I'm asking, should you have more insight on those flags...

I couldn't work out why SSL_VERIFY_POST_HANDSHAKE exists, but it didn't 
seem to make any difference in testing here.  Assumed I was being stupid 
but I've asked in https://github.com/openssl/openssl/issues/7178 now.

Regards, Joe

2.4.x and 2.6.x ... next steps

[Jim Jagielski]

I'd like for us to seriously consider the next steps
related to the future of httpd.

In trunk we have some stuff that can be easily, or, at
least, *somewhat* easily backported to 2.4.x, and I
personally think that we should do that. But we also
have some items which cannot be backported due to API/ABI
concerns, and some of these are pretty useful things.
And finally, we have some things in trunk that will likely
need to be majorly fixed or else scrapped.

The 1st thing we need to do is classify those things
within trunk. We then need to backport what we can,
and should, and then make progress on a 2.6.x release
(please note, I am using shorthand here... yes, I know
what we *really* do is a 2.5.x which then goes to 2.6.x
but I'm hopeful we all know what I mean).

This is what I propose:

  o Later on this week I svn cp trunk over to branches/2.5.x
  o That branch becomes the initial source for 2.6.x
  o trunk remains CTR, whereas branches/2.5.x becomes RTC
ala 2.4.x (ie: using STATUS and specific, targeted
backport requests).
  o Backports to 2.4.x only come from 2.5.x
  o We then release a 2nd alpha from branches/2.5.x
  o We get 2.5.x into a releasable stage, whereas we
svn mv branches/2.5.x to branches/2.6.x

A combination of trunk's STATUS and 2.4.x's STATUS will
become the STATUS for 2.5.x... see below for the why (but
basically that file will serve as the place where those
above "classifications" will be documented).

The main goal is that this creates a somewhat "stable"
2.5.x branch which can be polished but as well serve as
the source for backports. Additional development continues
on trunk w/o mussing up 2.5.x... but there is also a path
that stuff in trunk can end-up in 2.6.x. In also allows us
to remove "experiments" in the old trunk (and now 2.5.x)
which are broken or, at least, doesn't have enough support
to warrant being released (a glance thru 2.4.x's STATUS file
for backports which are stagnated, etc provide some clues
on what those could be... at the least, this will provide
incentive to address those concerns or revert those additions)

For me, the main push for this are some of the various async
improvements in trunk that, at least from what I can tell,
simply cannot be backported. It is possible that those improvements
will be the primary and almost-singular distinction between
2.4.x and 2.6.x after all is said and done, but who knows...

Thoughts? Comments?

Re: 2.4.x and 2.6.x ... next steps

[Christophe JAILLET]

Le 11/09/2018 à 20:35, Jim Jagielski a écrit :

I'd like for us to seriously consider the next steps
related to the future of httpd.

In trunk we have some stuff that can be easily, or, at
least, *somewhat* easily backported to 2.4.x, and I
personally think that we should do that.

+1

But we also
have some items which cannot be backported due to API/ABI
concerns, and some of these are pretty useful things.
And finally, we have some things in trunk that will likely
need to be majorly fixed or else scrapped.

The 1st thing we need to do is classify those things
within trunk. We then need to backport what we can,
and should, and then make progress on a 2.6.x release
(please note, I am using shorthand here... yes, I know
what we *really* do is a 2.5.x which then goes to 2.6.x
but I'm hopeful we all know what I mean).

This is what I propose:

   o Later on this week I svn cp trunk over to branches/2.5.x
My only comment is that, from my personal point of view, we should start 
from branches/2.4.x and not from trunk.

See below why.


   o That branch becomes the initial source for 2.6.x
   o trunk remains CTR, whereas branches/2.5.x becomes RTC
 ala 2.4.x (ie: using STATUS and specific, targeted
 backport requests).
   o Backports to 2.4.x only come from 2.5.x
   o We then release a 2nd alpha from branches/2.5.x
   o We get 2.5.x into a releasable stage, whereas we
 svn mv branches/2.5.x to branches/2.6.x

A combination of trunk's STATUS and 2.4.x's STATUS will
become the STATUS for 2.5.x... see below for the why (but
basically that file will serve as the place where those
above "classifications" will be documented).

The main goal is that this creates a somewhat "stable"
2.5.x branch which can be polished but as well serve as
the source for backports. Additional development continues
on trunk w/o mussing up 2.5.x... but there is also a path
that stuff in trunk can end-up in 2.6.x. In also allows us
to remove "experiments" in the old trunk (and now 2.5.x)
which are broken or, at least, doesn't have enough support
to warrant being released (a glance thru 2.4.x's STATUS file
for backports which are stagnated, etc provide some clues
on what those could be... at the least, this will provide
incentive to address those concerns or revert those additions)


This is why I think that backporting (and/or cleaning trunk) is easier 
to manage than removing "experiments".

We know, and eventually can vote to have more reviews if we backport.
We can have "experiments" stay in 2.5.x/2.6 if no-one pays attention to it.

I have in mind a discussion between Yann and William about a potential 
past issue that could have been re-introduced by a recent optimization.
There was no clear status if it was an issue or not, but if it was, it 
would silently be re-introduced.
(I've not been able to find the corresponding mails, will try to dig 
further tomorrow evening)




For me, the main push for this are some of the various async
improvements in trunk that, at least from what I can tell,
simply cannot be backported. It is possible that those improvements
will be the primary and almost-singular distinction between
2.4.x and 2.6.x after all is said and done, but who knows...

Thoughts? Comments?

+ clearly document the changes in 2.4 -> 2.5/2.6, to start building the 
next https://httpd.apache.org/docs/current/upgrading.html.

Re: 2.4.x and 2.6.x ... next steps

[Eric Covener]

> + clearly document the changes in 2.4 -> 2.5/2.6, to start building the
> next https://httpd.apache.org/docs/current/upgrading.html.

as well as docs/manual/new_features_2.5.xml

I am not sure 2.6 has much to offer. But it's a bit of a
chicken-and-egg problem I guess.

-- 
Eric Covener
cove...@gmail.com

Re: 2.4.x and 2.6.x ... next steps

[Yann Ylavic]

On Tue, Sep 11, 2018 at 10:07 PM Christophe JAILLET
 wrote:
>
> Le 11/09/2018 à 20:35, Jim Jagielski a écrit :
> > I'd like for us to seriously consider the next steps
> > related to the future of httpd.

++1

> > This is what I propose:
> >
> >o Later on this week I svn cp trunk over to branches/2.5.x
> My only comment is that, from my personal point of view, we should start
> from branches/2.4.x and not from trunk.
> See below why.
>
> >o That branch becomes the initial source for 2.6.x
> >o trunk remains CTR, whereas branches/2.5.x becomes RTC
> >  ala 2.4.x (ie: using STATUS and specific, targeted
> >  backport requests).
> >o Backports to 2.4.x only come from 2.5.x
> >o We then release a 2nd alpha from branches/2.5.x
> >o We get 2.5.x into a releasable stage, whereas we
> >  svn mv branches/2.5.x to branches/2.6.x

LGTM, thanks for being clear on this!

> > The main goal is that this creates a somewhat "stable"
> > 2.5.x branch which can be polished but as well serve as
> > the source for backports. Additional development continues
> > on trunk w/o mussing up 2.5.x... but there is also a path
> > that stuff in trunk can end-up in 2.6.x. In also allows us
> > to remove "experiments" in the old trunk (and now 2.5.x)
> > which are broken or, at least, doesn't have enough support
> > to warrant being released (a glance thru 2.4.x's STATUS file
> > for backports which are stagnated, etc provide some clues
> > on what those could be... at the least, this will provide
> > incentive to address those concerns or revert those additions)
>
> This is why I think that backporting (and/or cleaning trunk) is easier
> to manage than removing "experiments".
> We know, and eventually can vote to have more reviews if we backport.
> We can have "experiments" stay in 2.5.x/2.6 if no-one pays attention to it.

This would let trunk in a less controlled state than Jim's proposal
IMHO, complicating future backports to 2.6.x.
I wish we could "cleanup" trunk from our work/findings on what 2.6
should be, there is probably few gains to let things in trunk if they
don't fit in 2.6.

>
> I have in mind a discussion between Yann and William about a potential
> past issue that could have been re-introduced by a recent optimization.
> There was no clear status if it was an issue or not, but if it was, it
> would silently be re-introduced.
> (I've not been able to find the corresponding mails, will try to dig
> further tomorrow evening)

Possibly: 
https://lists.apache.org/thread.html/%3ccakq1svnw_vdpbzk6c+f30y5nbhhosbbwt_fubttsnc+r7mb...@mail.gmail.com%3E
?
That was a proposal (nothing committed), I don't think the regression
suspected by Bill was there, but had to work on something else so
couldn't test it... and then forgot about it :/
Thanks for the reminder ;)

Anyway, I see what you mean but is it better to leave such potential
bugs in trunk? Wider 2.5 testing and early 2.6 versions are meant to
catch them IMO.


Regards,
Yann.

Re: 2.4.x and 2.6.x ... next steps

[Graham Leggett]

On 11 Sep 2018, at 20:35, Jim Jagielski  wrote:

> This is what I propose:
> 
>  o Later on this week I svn cp trunk over to branches/2.5.x
>  o That branch becomes the initial source for 2.6.x
>  o trunk remains CTR, whereas branches/2.5.x becomes RTC
>ala 2.4.x (ie: using STATUS and specific, targeted
>backport requests).
>  o Backports to 2.4.x only come from 2.5.x
>  o We then release a 2nd alpha from branches/2.5.x
>  o We get 2.5.x into a releasable stage, whereas we
>svn mv branches/2.5.x to branches/2.6.x

+1.

To clarify the above, this describes what we did last time when we went from 
2.2 to 2.4. Nothing about the above is out of the ordinary based on what we’ve 
done in the past.

Regards,
Graham
—

Re: 2.4.x and 2.6.x ... next steps

[William A Rowe Jr]

On Tue, Sep 11, 2018, 17:42 Graham Leggett  wrote:

> On 11 Sep 2018, at 20:35, Jim Jagielski  wrote:
>
> > This is what I propose:
> >
> >  o Later on this week I svn cp trunk over to branches/2.5.x
>

-1 ... Veto on the basis of project bylaws. Propose a revision for voting.

>  o That branch becomes the initial source for 2.6.x
>

As practiced in 2.1 and 2.3, trunk, forked to 2.6, is the basis for release
branches.

>  o trunk remains CTR, whereas branches/2.5.x becomes RTC
>

The alpha/beta branches 2.1, 2.3 were never RTC. Veto based on project
guidelines.

>ala 2.4.x (ie: using STATUS and specific, targeted
> >backport requests).
> >  o Backports to 2.4.x only come from 2.5.x

>  o We then release a 2nd alpha from branches/2.5.x
> >  o We get 2.5.x into a releasable stage, whereas we
> >svn mv branches/2.5.x to branches/2.6.x
>
> +1.
>

-1. svn cp trunk 2.6.x.

To clarify the above, this describes what we did last time when we went
> from 2.2 to 2.4.


You are entirely misinformed.

When we went from 2.2 (and 2.0) we remained on trunk.

2.3 (and 2.1) was unstable, API's changed, MMN major was bumped every time
it was a breaking change.

The code on trunk is always CTR.

When we went from 2.3 (and 2.1) we forked trunk.

The code following the first GA release is RTC.

Nothing about the above is out of the ordinary based on what we’ve done in
> the past.
>

No, we have never begun a new major.minor branch as RTC.

We have never dropped code without requiring an actual veto, or the
committee withdrawing their code.

This is an attempt to turn httpd into an RTC project.

This is an attempt to discard the work of all committers who were told
their code wouldn't be included until the next version major.minor.
Complete disenfranchisement via a pocket veto of all changes.

If this is desirable, hold a discussion and then vote on project
bylaws/guidelines revisions to make that happen.

If it desireable, hold a vote to discard trunk altogether, svn rm it, and
replace it with 2.4.x branch.

The very idea that this is how httpd (or sibling projects such as apr or
Perl) have ever conducted ourselves is absurd.

If you want an example of how this goes wrong and how it has been addressed
elsewhere, the OpenSSL project git history is a good place to start.

But let's not start introducing fictions that httpd project has followed
the track above. During 2.4.0 phase, we did in fact drop out the apreq API
by backing up to before that addition, based on the belief at that time
that it was not mature enough. Otherwise the RTC trunk 2.3.x became CTR
2.4.x branch.

Re: 2.4.x and 2.6.x ... next steps

[William A Rowe Jr]

On Tue, Sep 11, 2018, 13:35 Jim Jagielski  wrote:

>
> And finally, we have some things in trunk that will likely
> need to be majorly fixed or else scrapped.
>

Please catalog these things.

The reason that even-odds minor versions exist is to clean up trunk for a
GA release. Otherwise we would have stayed with the 2.0.x release model.

RTC -> CTR between trunk n.odd releases and branched n.even GA releases was
a carefully choregraphed compromise between PMC members who wanted a
dynamic project and PMC members who wanted stability.

Hijacking the project to follow only one of those models is to
disenfranchise the other side of the community, which is a pretty abrupt
slap at ASF values.

You are right that what is on trunk needs the consideration of alpha and
beta releases to meet with our collective approval, and is not at this time
ready for GA.

Since every change has passed through trunk and every committer has
reviewed their patches against their own build of trunk, it's laughable to
suggest that trunk is 'unstable'.

For someone who strongly agrees merit never expires to suggest discarding
the work of all committers whose works were 'to be included' in 2.5 flies
in the face of all founding principals I'm aware of.

Please reconsider your proposal in light of this simple objection out of
respect for your fellow committers.

Re: 2.4.x and 2.6.x ... next steps

[Christophe JAILLET]

Le 12/09/2018 à 00:25, Yann Ylavic a écrit :
Possibly: 
https://lists.apache.org/thread.html/%3ccakq1svnw_vdpbzk6c+f30y5nbhhosbbwt_fubttsnc+r7mb...@mail.gmail.com%3E 


?
That was a proposal (nothing committed), I don't think the regression
suspected by Bill was there, but had to work on something else so
couldn't test it... and then forgot about it :/

That is what I was looking for, yes.


Thanks for the reminder ;)

Anyway, I see what you mean but is it better to leave such potential
bugs in trunk? Wider 2.5 testing and early 2.6 versions are meant to
catch them IMO.
I didn't say explicitly, but trunk should be cleaned up from what is now 
un-wanted/un-complete/(un-tested)...
I'm not a big fan of CTR because one may start something, never finish 
it for some reason, and it stays there, as is, and little by little no 
one remind the state of it.
Explicit backport (with votes) from trunk to 2.5 would only be there to 
have some explicit R.


As an example, all items in "PATCHES/ISSUES THAT ARE BEING WORKED" and 
"PATCHES/ISSUES THAT ARE STALLED" in 2.4.x/STATUS would be "silently" 
accepted.


Should anyone remove from trunk what he thinks as un-wanted?
Should we have some kind of RTC process for removing things that have 
been in trunk for a too long time and looks spurious?



Regards,
Yann.

Re: 2.4.x and 2.6.x ... next steps

[Christophe JAILLET]

Le 12/09/2018 à 03:15, William A Rowe Jr a écrit :
On Tue, Sep 11, 2018, 17:42 Graham Leggett > wrote:


On 11 Sep 2018, at 20:35, Jim Jagielski  wrote:

> This is what I propose:
>
>  o Later on this week I svn cp trunk over to branches/2.5.x


-1 ... Veto on the basis of project bylaws. Propose a revision for voting.

>  o That branch becomes the initial source for 2.6.x


As practiced in 2.1 and 2.3, trunk, forked to 2.6, is the basis for 
release branches.


>  o trunk remains CTR, whereas branches/2.5.x becomes RTC


The alpha/beta branches 2.1, 2.3 were never RTC. Veto based on project 
guidelines.


>    ala 2.4.x (ie: using STATUS and specific, targeted
>    backport requests).
>  o Backports to 2.4.x only come from 2.5.x

>  o We then release a 2nd alpha from branches/2.5.x
>  o We get 2.5.x into a releasable stage, whereas we
>    svn mv branches/2.5.x to branches/2.6.x

+1.


-1. svn cp trunk 2.6.x.

To clarify the above, this describes what we did last time when we
went from 2.2 to 2.4. 



You are entirely misinformed.

When we went from 2.2 (and 2.0) we remained on trunk.

2.3 (and 2.1) was unstable, API's changed, MMN major was bumped every 
time it was a breaking change.


The code on trunk is always CTR.

When we went from 2.3 (and 2.1) we forked trunk.

The code following the first GA release is RTC.

Nothing about the above is out of the ordinary based on what we’ve
done in the past.


No, we have never begun a new major.minor branch as RTC.

We have never dropped code without requiring an actual veto, or the 
committee withdrawing their code.


This is an attempt to turn httpd into an RTC project.

This is an attempt to discard the work of all committers who were told 
their code wouldn't be included until the next version major.minor. 
Complete disenfranchisement via a pocket veto of all changes.


If this is desirable, hold a discussion and then vote on project 
bylaws/guidelines revisions to make that happen.


If it desireable, hold a vote to discard trunk altogether, svn rm it, 
and replace it with 2.4.x branch.


The very idea that this is how httpd (or sibling projects such as apr 
or Perl) have ever conducted ourselves is absurd.


If you want an example of how this goes wrong and how it has been 
addressed elsewhere, the OpenSSL project git history is a good place 
to start.


But let's not start introducing fictions that httpd project has 
followed the track above. During 2.4.0 phase, we did in fact drop out 
the apreq API by backing up to before that addition, based on the 
belief at that time that it was not mature enough. Otherwise the RTC 
trunk 2.3.x became CTR 2.4.x branch.




I don't have in mind all this history of the past releases.
Should 2. be CTR and 2. RTC is just fine to me, even if I 
personally prefer RTC. My goal is not to slow done anything or prevent 
any new feature to be released. RTC, in my mind, is safer, that's all I 
mean.


As you have already noted too many times, nearly all recent 2.4.x 
releases have introduced some regressions.
This is sad and I wouldn't like 2.6 to be worse because of a lack of 
review/acceptance in new features.


RTC doesn't prevent regression (all backports in the recent 2.4.x have 
been reviewed and voted). It may catch some.


If the idea that 2.6 may introduced some issues and that the 2.5 cycle 
is there to try to fix as many of them as possible, this is fine to me.


As already said in another reply, all items in "PATCHES/ISSUES THAT ARE 
BEING WORKED" (i.e. un-finished?) and "PATCHES/ISSUES THAT ARE STALLED" 
(i.e. with issues or disagreements?) in 2.4.x/STATUS would be "silently" 
accepted.

That's my only concern.
(and building afterwards, from scratch, the list of all disruptive 
modifications can be painful, I guess)



CJ

Re: 2.4.x and 2.6.x ... next steps

[Christophe JAILLET]

I should have read this (shorter) reply first :)

Le 12/09/2018 à 03:30, William A Rowe Jr a écrit :



On Tue, Sep 11, 2018, 13:35 Jim Jagielski > wrote:



And finally, we have some things in trunk that will likely
need to be majorly fixed or else scrapped.


Please catalog these things.

The reason that even-odds minor versions exist is to clean up trunk 
for a GA release. Otherwise we would have stayed with the 2.0.x 
release model.


RTC -> CTR between trunk n.odd releases and branched n.even GA 
releases was a carefully choregraphed compromise between PMC members 
who wanted a dynamic project and PMC members who wanted stability.


Hijacking the project to follow only one of those models is to 
disenfranchise the other side of the community, which is a pretty 
abrupt slap at ASF values.


You are right that what is on trunk needs the consideration of alpha 
and beta releases to meet with our collective approval, and is not at 
this time ready for GA.



That's my point.

Since every change has passed through trunk and every committer has 
reviewed their patches against their own build of trunk, it's 
laughable to suggest that trunk is 'unstable'.



2 examples from me:
https://bz.apache.org/bugzilla/show_bug.cgi?id=59636.
I suspect that what have been committed by me is incomplete. And it is 
still un-fixed (by me)



https://bz.apache.org/bugzilla/show_bug.cgi?id=44221
I though my patches was right. It was discussed and controversial 
(change of default was not expected on a stable branch, but maybe could 
on a new one?)

This has remained as-is for almost 4 years now.
Should be reworked (to keep the default behavior), or well documented 
(to avoid surprise when s.o. upgrades) or axed (if not correctly done 
and still unfixed)

But It should not go as-is, IMHO, in a new release.


So, I wouldn't say 'unstable', but at least in some cases, 'not as good 
as it deserve'.
For someone who strongly agrees merit never expires to suggest 
discarding the work of all committers whose works were 'to be 
included' in 2.5 flies in the face of all founding principals I'm 
aware of.


Please reconsider your proposal in light of this simple objection out 
of respect for your fellow committers.




CJ