On Sat, Nov 4, 2017 at 10:48 AM, Eric Covener <cove...@gmail.com> wrote: > On Sat, Nov 4, 2017 at 9:28 AM, Marion & Christophe JAILLET > <christophe.jail...@wanadoo.fr> wrote: >> Hi, >> >> So 2.5.0-alpha will be RTC.
Howso? I haven't seen a vote. There can be no 2.5.x-GA. We only deliver 2.5.x-alpha|beta. Without a proposal followed by a majority vote, this is the process we adopted and documented long ago and follow to this day. For very specific reasons... As a committee we long ago voted that GA releases follow RTC and development follows CTR. You can find the very lengthy debates on the merits in dev@ list history. This was a compromise between committers who support current users and hate disruption, and committers with new ideas who hate obstacles to development. The compromise ensured the released software was generally not disruptively changed, while the project as a whole was not closed off to evolution. Two different groups of committers, two different solutions. When only one development methodology is permitted, only one group of committers will remain. We are largely already there, if you look at the list of contributors to that compromise. > It is not clear to me when we'd branch trunk to 2.5 vs. just rolling > alphas from trunk. There is a valid point that once the ABI of a 2.next is stable, that it is disruptive to development/developers, and they need a place to commit code, so a fork at ABI-stable makes sense. 2.5.x-alpha is nowhere near being declared stable. >> Will it be a fork of latest 2.4.x and trunk things will have to be >> proposed, voted and backported? That is not how httpd has operated previously. Again, a proposal to change the process and a vote is needed if this is desired. I expect it will result in the final arc of project stagnation. >> Or will it be a fork from trunk with things likely never (IMHO) really >> reviewed? Thanks for clarifying this is your opinion, shared by several others. I strongly disagree. Our responsibility is to monitor code contributed to httpd, as both PMC and project committers. There has been plenty of specific technical feedback to some significant number of commits to trunk, before they were ever proposed for backport. Committers do watch commits@. If your and other's opinion is true, it seems this is a reflection of a 7-year technical deficit of not watching commits yourself as closely as you wished to. Trashing 7 years of activity over personal lack of attention seems to be the worst possible outcome for the health of a publicly coded open source project. >> My own opinion is a copy of 2.4.x + RTC process because I think it is >> safer. But I'm not sure it is what others have in mind. > > Definitely trunk, but I considered this same kind of 2.4->2.5 proposal > but decided to keep quiet. A big dependency on this choice is the > goals and the effect on people with other goals. 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. I view this proposal as an acknowledgement that httpd has been completed, that further evolution is not realistic, and httpd's current adoption glide-path is terminal. All software reaches end-of-life. I haven't booted CP/M in the past 20 years. I haven't used kermit in 25. Not even a telnet session in the past 15 yrs. But I'm hoping httpd isn't at this point. The CTR/RTC even-odds was baked to compromise between this stale, uncompromising "gatekeeper" approach to httpd maintenance, and fresh httpd coding. But because further version major.minor releases were abandoned, a large amount of disruptive code keeps landing on the maintenance branch, because "there are no other prospects" for ever getting the code released. The worst offenders of throwing fresh new development at what others wish to be a maintenance branch are the very same who had argued against another trunk release whatsoever. Why? Because of this very dichotomy. "I don't want to see regressions in httpd. But I want my code released." And so, we have the worst of both outcomes, a disruptive "stable" and a dead "development" avenue. If this is in fact the state of httpd, that trunk/ can no longer be released, that committers and PMC performed no oversight of the repository, it seems like a stunning indictment of all of us, and the obvious reaction by ASF board would be to strip the committer privileges of all, dissolve the PMC, and use the metric of trunk commit -> dev@ feedback to repopulate the project with those who demonstrated some participation over the trunk/ review process within the past seven years. Every ex-officer of the project and foundation would be ineligible to participate as a PMC or committer due to willful negligence for any such a restart, myself included. I'm not that pessimistic. I did read commits. I build and run trunk. I don't know that they don't contain bugs. This is the value of all of our previous lengthy alpha -> beta transition phases. And I expect nothing different this cycle, a testing and review cycle to validate the current state of the code. HOWEVER, if there are committers with an itch to scratch, who want to take modules or mpms or core functionality or even main() to task and review these line by line for all of the intended development changes that live on trunk... that is an itch. Nobody would block or disrespect reports of any human-iterated audit of the state of our code, from any of a delta-view, fuzzing results, whitehat vulnerability probes or any of dozens of other methodologies to find flaws. (We will regularly dismiss automated discovery of ""defects"" which are no such thing, and when given a dump from such tools, nobody here has the patience to find the five gold invitations in a pile of 1,600 "issues".) The sooner we publish 2.5.x-alpha, the sooner we resurrect our committers efforts to improve httpd, and the later the eventual retirement of this project will occur. Let's get testing and reviewing, thank you Daniel for simplifying this workflow!
