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!

Reply via email to