Re: Cool Stuff In trunk: (Was: Re: 2.4.x and 2.6.x ... next steps)

[Yann Ylavic]

On Wed, Sep 12, 2018 at 2:57 PM Stefan Eissing
 wrote:
>
>
> > Am 12.09.2018 um 14:48 schrieb Jim Jagielski :
> >
> > As I said before, the main assumption in my suggestion is that there are 
> > things in trunk that "really should" be in some releasable version, stuff 
> > significant enough to warrant the work, but is "impossible" to be 
> > backported to 2.4.
> >
> > If there are no real significant-but-impossible-to-backport features in 
> > trunk, then the proposal itself is moot.
> >
> > So let's think about it: What is currently in trunk that is a pretty 
> > significant improvement? Then ask if it is directly backportable. Certainly 
> > the effort in backporting from trunk to 2.4.x is much less than the effort 
> > in spinning out 2.6.x and considering all things, that should be the 
> > primary flow.
>
> There are things I'd like to do for 2.5.x-to-become-2.6 releases that I 
> cannot to in 2.4.x and will not do before that. I assume this holds also true 
> for others.

+1

FWIW I've got WIP on async mod_proxy_http (based on wstunnel/event "go
async" mode, with common functions put in proxy_util, the pump/forward
loop from PR 61616, websocket proxying friendly).
Of course I'll propose it on dev@ first, and if it's received
positively that could make great stuff for 2.6, but not for 2.4 where
modules are not really prepared to be changed their running thread
underneath them...

>
> To put it another way: current trunk is dead code to me. Only a stopover for 
> 2.4.x (aka release version). For the last three years, it was just in the way.

That can't/shouldn't be, trunk is where we do improvements AND the
next released version.
Once we take less care of 2.4 compat, things become much easier IMHO.

>
> Or another way: I am too old to commit to trunk only. ;)

I'm sure that trunk + all of your (and others) pending stuff made to
2.6 and you go for a new youth :)

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

[Jim Jagielski]

> On Sep 12, 2018, at 10:27 AM, Stefan Eissing  
> wrote:
> 
> I feel myself in agreement with Bill that trunk needs to be where 2.5.x is 
> born.
> 

It is. That should be clear in the proposal.

What should also be clear is that there is a LOT in trunk that should be in 
2.4.x and has nothing to do with 2.5/2.6/3.0/next-gen. So backporting that 
stuff HELPS midwifing 2.5/2.6!

Re: Cool Stuff In trunk: (Was: Re: 2.4.x and 2.6.x ... next steps)

[Jim Jagielski]

Thanks, this is useful.

At first blush, this looks like there is a crap-ton of stuff in trunk than can, 
and should, be quickly and easily backported to 2.4 asap!!

> On Sep 12, 2018, at 10:06 AM, William A Rowe Jr  wrote:
> 
> On Wed, Sep 12, 2018 at 7:49 AM Jim Jagielski  > wrote:
> As I said before, the main assumption in my suggestion is that there are 
> things in trunk that "really should" be in some releasable version
> 
> Everything in trunk is now digested into three groups of commits, for 
> inspection. These don't include whitespace changes, so the resulting files 
> may be mis-indented and otherwise skewed, but we are looking for changes, not 
> insignificant formatting;
> 
> Just the docs (sources, and generated)
> http://svn.apache.org/viewvc?view=revision&revision=1840682 
> 
> http://svn.apache.org/viewvc?view=revision&revision=1840684 
> 
> 
> Just win32 generated build gunk (presuming vcproj and CMake are both winners, 
> there is a discussion to be had on .mak files before this gap is addressed)
> http://svn.apache.org/viewvc?view=revision&revision=1840687 
> 
> 
> Everything else (all the interesting stuff)
> http://svn.apache.org/viewvc?view=revision&revision=1840688 
>  
> 
> I expect committers will be mostly interested in the last link above.
> 

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

[William A Rowe Jr]

On Wed, Sep 12, 2018, 09:19 Graham Leggett  wrote:

> On 12 Sep 2018, at 15:39, William A Rowe Jr  wrote:
>
> > Now, why would we *need* a 2.5.x branch?
>
> The primary need is to remove stuff that we deem not-ready-for-2.6-yet.
> Modules without any docs for example would need to be either documented or
> removed-from-2.5-that-will-become-2.6, keeping trunk as it is.


If it is not ready, it should not pollute trunk. Think of this as an
exercise to prune things unlikely to ever be hashed out completely. Why put
off the inevitable and force this set of issues on the 2.7.x maintainers
down the road?

We have a sandbox; things that must still be proven up need to be moved
there and pruned sometime in the next 10 years, if then.

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

[Stefan Eissing]

> Am 12.09.2018 um 16:19 schrieb Graham Leggett :
> 
> On 12 Sep 2018, at 15:39, William A Rowe Jr  wrote:
> 
>> Now, why would we *need* a 2.5.x branch?
> 
> The primary need is to remove stuff that we deem not-ready-for-2.6-yet. 
> Modules without any docs for example would need to be either documented or 
> removed-from-2.5-that-will-become-2.6, keeping trunk as it is.
> 
> We don’t want to remove work from trunk that needs polishing for the reasons 
> you’ve already described.

While we certainly do not want to dis any work in progress - and I think no one 
has that intention - trunk needs to be clean and ready for beta releases. 
Otherwise, it is just more work for all contributors. Someone who gets stuck in 
development of a feature should move it to its own feature branch for that very 
reason.

I feel myself in agreement with Bill that trunk needs to be where 2.5.x is born.

-Stefan

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

[William A Rowe Jr]

Going to largely ignore most other input on this thread, beyond the
underlying proposals to branch 2.5.x and move to RTC...

On Wed, Sep 12, 2018, 03:20 Stefan Eissing 
wrote:

> In my estimation, cleaning up trunk (or a copy of it) via RTC will take
> forever, at least.
>
> And while that continues, any bugfix can only be done in trunk. We then
> need 2(!) RTC proposals and votes per fix if it affects 2.4.x. (Which,
> until 2.6 is out and gets adopted, will be the case almost all of the time.)
>
> We do not even find enough people to look at the proposals for 2.4.x. It's
> easier to find people outside the project to test fixes in their production
> systems.
>
> Short: I  do not believe this can work.
>

I completely agree.

If we pause to consider how we got to http2 already, it was because of
Stefan's massive efforts *in CTR mode*. Would this have been a reasonable
project to launch in RTC? IMO, no.

If we trust our committers, CTR will let us make far more progress in far
less time. Note that all major proposals must be taken to the dev list
anyways.

Note that RTC fails to intercept as many bugs as it catches, as easily
observed during the 2.4.x generation, but at a very large cost in terms of
development feedback loop timing.

If we do not trust our committers we have a much different issue that RTC
does not address.

2.5.x are entirely alpha/beta releases, nobody will flinch at a regression
or bug.

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

[Jim Jagielski]

> On Sep 12, 2018, at 9:39 AM, William A Rowe Jr  wrote:
> 
> 
> So although others mentioned 2.4.x branch, this is not the origin of YOUR 
> proposal. Wow, that simplifies this discussion a lot (and hopefully, our new 
> committers who never even corresponded with some long absent colleagues now 
> see my concern with the dismissiveness against using trunk.) Sorry that I 
> misattributed that part of the discussion to your proposal.
> 
> Here is the problem I have with forking today. I expect you know I have no 
> problem with tagging 2.5.1-alpha any day of the week and putting 2.5 
> candidates up for release vote.
> 
> During the 'development' of 2.odd we have no need to fork, because all 
> API/ABI changes are permitted between 2.5.1 and 2.5.2. Our trunk needs to be 
> usable all the time, not just during this release prep. But, forking 
> introduces a mess of svn maintenance to no justified purpose.
> 
> And most of all, we need to trust our fellow committers. It is clear that 
> review before or after does not eliminate all errors. But 2.5 will not be GA 
> (2.6 will be.)
> 
> The straight line, avoiding a ton of excess backports, and keeping it simple 
> on the RM, is to either 1. Tag from the final, accepted 2.5.x svn commit rev 
> into 2.6.x branch, or 2. from trunk to 2.6.x branch if the RM believes the 
> changes are limited risk, and can be vetted during the release vote.
> 
> Forking 2.5.x says, outright, I don't trust my fellow committers with commit 
> bits to the alpha/beta development branch. That is also a bad signal to send 

Not at all. It sez "here is a safe space to continue to go wild and here is a 
place where there is an expected direct path to a releasable version"... no 
diff from when we had httpd-2.2, httpd-2.4 and trunk. We just have httpd-2.4, 
httpd-2.5 and trunk.

And again, ALL of this is predicated on the assumption that there is stuff in 
trunk (really useful and tested stuff) that cannot be backported to 2.4. 
Obviously, it is a lot easier, and takes a lot less time, to continue as we are 
and backport as we can; even some of the "impossible" stuff may actually be 
backportable with less effort than spinning 2.5/2.6. And, again personally, I 
think we are doing an extremely good job in balancing things between trunk and 
httpd-2.4, with most divergences either fluff or sandbox-type refactorings that 
may not pass muster when all is said and done.

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

[Graham Leggett]

On 12 Sep 2018, at 15:39, William A Rowe Jr  wrote:

> Now, why would we *need* a 2.5.x branch?

The primary need is to remove stuff that we deem not-ready-for-2.6-yet. Modules 
without any docs for example would need to be either documented or 
removed-from-2.5-that-will-become-2.6, keeping trunk as it is.

We don’t want to remove work from trunk that needs polishing for the reasons 
you’ve already described.

Regards,
Graham
—

Re: Cool Stuff In trunk: (Was: Re: 2.4.x and 2.6.x ... next steps)

[William A Rowe Jr]

On Wed, Sep 12, 2018 at 7:49 AM Jim Jagielski  wrote:

> As I said before, the main assumption in my suggestion is that there are
> things in trunk that "really should" be in some releasable version


Everything in trunk is now digested into three groups of commits, for
inspection. These don't include whitespace changes, so the resulting files
may be mis-indented and otherwise skewed, but we are looking for changes,
not insignificant formatting;

Just the docs (sources, and generated)
http://svn.apache.org/viewvc?view=revision&revision=1840682
http://svn.apache.org/viewvc?view=revision&revision=1840684

Just win32 generated build gunk (presuming vcproj and CMake are both
winners, there is a discussion to be had on .mak files before this gap is
addressed)
http://svn.apache.org/viewvc?view=revision&revision=1840687

Everything else (all the interesting stuff)
http://svn.apache.org/viewvc?view=revision&revision=1840688

I expect committers will be mostly interested in the last link above.

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

[William A Rowe Jr]

On Wed, Sep 12, 2018, 07:41 Jim Jagielski  wrote:

> Ahh. I think I see the problem! For some reason Bill sees this as somehow
> Jim's (my) fork. It's not. It's a  svn branch from HEAD of trunk, which
> contains
> all the changes. That branch is the projects's branch not some personal
> fork, whatever that means.
>

So although others mentioned 2.4.x branch, this is not the origin of YOUR
proposal. Wow, that simplifies this discussion a lot (and hopefully, our
new committers who never even corresponded with some long absent colleagues
now see my concern with the dismissiveness against using trunk.) Sorry that
I misattributed that part of the discussion to your proposal.

Here is the problem I have with forking today. I expect you know I have no
problem with tagging 2.5.1-alpha any day of the week and putting 2.5
candidates up for release vote.

During the 'development' of 2.odd we have no need to fork, because all
API/ABI changes are permitted between 2.5.1 and 2.5.2. Our trunk needs to
be usable all the time, not just during this release prep. But, forking
introduces a mess of svn maintenance to no justified purpose.

And most of all, we need to trust our fellow committers. It is clear that
review before or after does not eliminate all errors. But 2.5 will not be
GA (2.6 will be.)

The straight line, avoiding a ton of excess backports, and keeping it
simple on the RM, is to either 1. Tag from the final, accepted 2.5.x svn
commit rev into 2.6.x branch, or 2. from trunk to 2.6.x branch if the RM
believes the changes are limited risk, and can be vetted during the release
vote.

Forking 2.5.x says, outright, I don't trust my fellow committers with
commit bits to the alpha/beta development branch. That is also a bad signal
to send

Now, why would we *need* a 2.5.x branch? The only thing I can picture is
someone proposes post-2.6 work. And for the time being, such work can and
should live in a sandbox, imo.

Again, sorry I missed the transition from discussing trunk to discussing
2.4.x branch. I completely support your initial suggestion of the basis,
modulo tagging these pre-2.6.0 candidates directly on trunk.

Re: Cool Stuff In trunk: (Was: Re: 2.4.x and 2.6.x ... next steps)

[Stefan Eissing]

> Am 12.09.2018 um 14:48 schrieb Jim Jagielski :
> 
> As I said before, the main assumption in my suggestion is that there are 
> things in trunk that "really should" be in some releasable version, stuff 
> significant enough to warrant the work, but is "impossible" to be backported 
> to 2.4.
> 
> If there are no real significant-but-impossible-to-backport features in 
> trunk, then the proposal itself is moot.
> 
> So let's think about it: What is currently in trunk that is a pretty 
> significant improvement? Then ask if it is directly backportable. Certainly 
> the effort in backporting from trunk to 2.4.x is much less than the effort in 
> spinning out 2.6.x and considering all things, that should be the primary 
> flow.

There are things I'd like to do for 2.5.x-to-become-2.6 releases that I cannot 
to in 2.4.x and will not do before that. I assume this holds also true for 
others.

To put it another way: current trunk is dead code to me. Only a stopover for 
2.4.x (aka release version). For the last three years, it was just in the way.

Or another way: I am too old to commit to trunk only. ;)

-Stefan

Cool Stuff In trunk: (Was: Re: 2.4.x and 2.6.x ... next steps)

[Jim Jagielski]

As I said before, the main assumption in my suggestion is that there are things 
in trunk that "really should" be in some releasable version, stuff significant 
enough to warrant the work, but is "impossible" to be backported to 2.4.

If there are no real significant-but-impossible-to-backport features in trunk, 
then the proposal itself is moot.

So let's think about it: What is currently in trunk that is a pretty 
significant improvement? Then ask if it is directly backportable. Certainly the 
effort in backporting from trunk to 2.4.x is much less than the effort in 
spinning out 2.6.x and considering all things, that should be the primary flow.

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

[Jim Jagielski]

Ahh. I think I see the problem! For some reason Bill sees this as somehow
Jim's (my) fork. It's not. It's a  svn branch from HEAD of trunk, which contains
all the changes. That branch is the projects's branch not some personal
fork, whatever that means.

> On Sep 12, 2018, at 6:49 AM, William A Rowe Jr  wrote:
> 
> On Wed, Sep 12, 2018, 04:16 Daniel Gruno  > wrote:
> On 09/12/2018 10:58 AM, Graham Leggett wrote:
> > On 12 Sep 2018, at 03:15, William A Rowe Jr  >  
> > >> wrote:
> > 
> >> 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.
> > 
> > I've totally lost you. Jim describes creating a branch, how is this 
> > related to voting?
> 
> I am not Bill, but it is likely a reference to the fact that you can 
> veto code changes, not community/workflow changes. I see Jim's proposal 
> as the latter, so I'm not sure why the attempted veto. The codebase 
> itself isn't being changed from what I can gather, only the workflow is.
> 
> Yes. To be clear, the proposal to make 2.5 Jim's fork, discarding all 
> previously committed changes to 2.5 (and I suppose, renumbering trunk as 2.7) 
> is a change to the project development process at httpd.
> 
> As-it-stands, such a personal fork is vetoable. And flies in sharp contrast 
> to community over code, discarding the existing collaboration of 2.5.1-dev 
> trunk in favor of one participants agenda.
> 
> Note, sandboxes are encouraged, don't require any vote to start one, and 
> might lead to some compromise between points a and b.
> 
> I suggest above, propose a *process* revision to our /dev/ docs for a vote, 
> before proceeding to violate community norms on versioning. Sorry for the 
> confusion about what I was proposing to 'revise'.
> 
> As a project committee vote to change our operational process, that is a 
> simple majority vote, as Daniel observes, which would carve out space for a 
> zombie (never to be released) trunk,

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

[Jim Jagielski]

> On Sep 11, 2018, at 4:57 PM, Eric Covener  wrote:
> 
>> + 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.

My thought was that the suspend stuff and async filters were
significant/useful enough and that they were un-backportable,
hence what I wrote in the last paragraph that that improvement
may be the only real diff between 2.4 and 2.6.

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

[Eric Covener]

> Yes. To be clear, the proposal to make 2.5 Jim's fork, discarding all 
> previously committed changes to 2.5 (and I suppose, renumbering trunk as 2.7) 
> is a change to the project development process at httpd.

What's being discarded in the proposal?

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

[William A Rowe Jr]

On Wed, Sep 12, 2018, 04:16 Daniel Gruno  wrote:

> On 09/12/2018 10:58 AM, Graham Leggett wrote:
> > On 12 Sep 2018, at 03:15, William A Rowe Jr  > > wrote:
> >
> >> 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.
> >
> > I've totally lost you. Jim describes creating a branch, how is this
> > related to voting?
>
> I am not Bill, but it is likely a reference to the fact that you can
> veto code changes, not community/workflow changes. I see Jim's proposal
> as the latter, so I'm not sure why the attempted veto. The codebase
> itself isn't being changed from what I can gather, only the workflow is.
>

Yes. To be clear, the proposal to make 2.5 Jim's fork, discarding all
previously committed changes to 2.5 (and I suppose, renumbering trunk as
2.7) is a change to the project development process at httpd.

As-it-stands, such a personal fork is vetoable. And flies in sharp contrast
to community over code, discarding the existing collaboration of 2.5.1-dev
trunk in favor of one participants agenda.

Note, sandboxes are encouraged, don't require any vote to start one, and
might lead to some compromise between points a and b.

I suggest above, propose a *process* revision to our /dev/ docs for a vote,
before proceeding to violate community norms on versioning. Sorry for the
confusion about what I was proposing to 'revise'.

As a project committee vote to change our operational process, that is a
simple majority vote, as Daniel observes, which would carve out space for a
zombie (never to be released) trunk,

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

[Daniel Gruno]

On 09/12/2018 10:58 AM, Graham Leggett wrote:
On 12 Sep 2018, at 03:15, William A Rowe Jr > wrote:


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


On 11 Sep 2018, at 20:35, Jim Jagielski mailto:j...@jagunet.com>> 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.


I've totally lost you. Jim describes creating a branch, how is this 
related to voting?


I am not Bill, but it is likely a reference to the fact that you can 
veto code changes, not community/workflow changes. I see Jim's proposal 
as the latter, so I'm not sure why the attempted veto. The codebase 
itself isn't being changed from what I can gather, only the workflow is.


With regards,
Daniel.



Rather than a wall of text, can you propose corrections to the above?

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.


Again, totally lost you. I can’t see anything in Jim’s proposal that 
suggests we throw away code or work from trunk, and I would not allow 
that to happen either. Have you mixed up the messages you’ve replied to?


Regards,
Graham
—

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

[Plüm , Rüdiger , Vodafone Group]

Von: William A Rowe Jr 
Gesendet: Mittwoch, 12. September 2018 03:15
An: httpd 
Betreff: Re: 2.4.x and 2.6.x ... next steps

On Tue, Sep 11, 2018, 17:42 Graham Leggett 
mailto:minf...@sharp.fm>> wrote:
On 11 Sep 2018, at 20:35, Jim Jagielski 
mailto:j...@jagunet.com>> wrote:



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

To my understanding we talk about code that “does not work” and has “issues”. 
So I have never seen a need to veto code in order to fix it. Fixing code can 
also include dropping parts of the code.
I guess you are more worried that we drop the code of complete “features” from 
trunk. As with other stuff I think we just need to discuss on dev@ if there are 
“features” that have issues that need to be fixed.
And if nobody pops up that wants or can fix these issues then dropping it is 
IMHO a valid option as well. If you want to do that via a formal veto on the 
original commit is another topic. I guess this is warranted for big
contributions like whole modules. I think that if we as a group decide in the 
open that a certain feature for a new major release is undesirable for whatever 
reason it is fine to drop it and thus the code even from trunk if nobody is 
willing to work on it and maintain it.
Actually the code will never be dropped. You just need to dig in the svn 
history to find it.
I think the whole point goes more in the direction that the review on trunk is 
sometimes too “sloopy” so that we accumulate unfinished, buggy and untested 
stuff instead of having these issues solved when the code was committed
and the contributor is still available and up to speed for discussion and 
resolution.
One other approach would point in the direction to have major releases more 
often such that these issues are detected earlier.
As proposed on this thread I guess a traversal of the stalled backport 
proposals for 2.4.x is a good starting point to pick up issues in trunk.
I guess we need to pay some price for getting 2.5.x / trunk in a GA releasable 
state in order to publish 2.6.x:


1.   Either we try to stabilize stuff on trunk, but this means we need to 
back down with new fancy ‘unstable’ commits on trunk (social rule not formal 
RTC).

2.   Or we add that 2.5.x branch which is RTC in between trunk and 2.4.x 
branch and thus slow down the backports to 2.4.

If there are enough people that can work on getting 2.5.x / trunk in a GA 
releasable state I think 1. or 2.  will not take long and thus are acceptable.
OTOH if doing that will become an endless story I think both approaches will 
create a lot of friction. Independent on which way we go we should possibly set 
a rough timeline for finishing this work and return to current state if it 
cannot be done this way in the timeline.

Regards

Rüdiger

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

[Graham Leggett]

On 12 Sep 2018, at 03:15, William A Rowe Jr  wrote:

> 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.

I've totally lost you. Jim describes creating a branch, how is this related to 
voting?

Rather than a wall of text, can you propose corrections to the above?

> 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.

Again, totally lost you. I can’t see anything in Jim’s proposal that suggests 
we throw away code or work from trunk, and I would not allow that to happen 
either. Have you mixed up the messages you’ve replied to?

Regards,
Graham
—

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

[Stefan Eissing]

In my estimation, cleaning up trunk (or a copy of it) via RTC will take 
forever, at least.

And while that continues, any bugfix can only be done in trunk. We then need 
2(!) RTC proposals and votes per fix if it affects 2.4.x. (Which, until 2.6 is 
out and gets adopted, will be the case almost all of the time.)

We do not even find enough people to look at the proposals for 2.4.x. It's 
easier to find people outside the project to test fixes in their production 
systems. 

Short: I do not believe this can work.

-Stefan

> Am 11.09.2018 um 20:35 schrieb 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]

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

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]

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

[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

[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

[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

[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

[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

[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.

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?