> On Nov 4, 2017, at 11:44 PM, William A Rowe Jr <[email protected]> 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.
