On Sun, Nov 5, 2017 at 3:44 PM, Jim Jagielski <j...@jagunet.com> wrote: > >> 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.
"This is good" is opinion, not fact. My opinion that preventing 2.6.0 from replacing insufficient APIs with cleaner APIs "is bad". Again, different value judgements from the same set of facts. > 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? And I agree with your encouragement, suggest that it is easier to read for content with -x --ignore-all-space. That has nothing to do with those committers who wish to work through 2.5.x towards 2|3.next. > 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. Reiterating again, that we disagree about who our preferred approaches are serving and they are disingenuous toward. Again, a value judgement. Neither of our value judgments need to "win". If one does "win", then a subset of the project consumers are poorly served. If they coexist, neither subset of the community needs to demand that others must scratch their own itch... what "encouragement" has escalated to. By unilaterally denying any future development releases, the project is locked in infinite "maintenance" releases. You can call these enhancements "improvements" and others can call these "destabilizing" and neither value judgement is necessarily wrong.