> On Nov 4, 2017, at 11:44 PM, William A Rowe Jr <wr...@rowe-clan.net> wrote:
> It is safer. It is incredibly time consuming to effectively perform
> a full audit of the state of trunk vs current. If we were to take this
> approach, it seems necessary to revert all of the unaccepted
> changes that live on trunk. E.g. rename trunk/ to scratchpad/
> and fork 2.4.x as trunk/ - 2.5.x.
> It is also disrespectful to our fellow committers who wrote and
> committed code to the next iteration of httpd. Few of them are
> still participating actively, which is little surprise given that their
> code is still not distributed after 7 years, and active committers
> are now advocating trashing it. Not only dismissing those who
> coded before you, but foretelling what contributors should
> expect of their contributions moving forwards.

IMO, we are not being disrespectful at all... we are actively
pushing code from trunk to 2.4.x, but only when the PMC
is ready, willing and able to "stand behind it", which
is done via a backport proposal and the required 3 +1s.
If the real goal and intent is to get that stuff out, then,
IMO at least, the "best" way to do it is to propose a
backport, or provide the backport, so that the PMC
can allow it to be in 2.4.x. I see many people doing
this. This is good for our contributors and our users.

I actually encourage people to:

  svn diff https://svn.apache.org/repos/asf/httpd/httpd/branches/2.4.x 
https://svn.apache.org/repos/asf/httpd/httpd/trunk | colordiff

and review the actual code diffs (a chunk of the diffs are in
the docs, *.mak or *.dep files). From those, which diffs
are really "unportable" to 2.4.x?

My reasons for "eager" back porting is that there are
things in trunk that people want, and need, *now*, not
as some nebulous time in the future when 2.6/3.0 is released
and GA and easily obtainable and readily bundled in distros.
Putting some arbitrary moratorium on backports simply
to force-drive 2.6/3.0 seems disingenuous to those
contributors and esp our users.

Reply via email to