Am 24.10.2017 um 00:17 schrieb William A Rowe Jr
<wr...@rowe-clan.net>:
Jim, you have very vocally and hostility reacted to *all* discussion
of improving the release process at the httpd project.
The project bylaws are clear, no individual PMC member may
block a release (the PMC chair may, owing to the fact that they
alone represent the board as the appointed VP, that's another
topic entirely.)
I have no evidence that you perceive a problem with the httpd
release status quo, and no evidence that you have reconsidered
your positions expressed during the past year, so I presume
none of these are changed, and further discussion is not
necessary at this step.
You've insisted we maintain the status quo with no changes,
and I'm proceeding based on our historical and documented
practices to move the project along. This is an obvious case
of agree-to-disagree, I accept your demand to hold to precedent,
and will proceed under that structure to ask wiling users to help
us determine the usability of the current code trunk/. In short,
you have engendered this solution.
This is only a starting point, not a result. Multiple -alphas will
usually occur, and I can't foresee any conclusions on a roadmap
before the end of the year, and a beta-worthy candidate before
the end of winter.
(Northern) winter tends to be a period of greater activity, summers
are very quiet in comparison. The approach to progress under our
existing model is incremental; code and release, code and release,
until the committee agrees that the code is ready to move from an
-alpha to a -beta, from a -beta to graduate to 2.6.0/3.0.0. This
approach avoids all personal conflicts by getting away from
people debating opinion or process, and going back to debating
the features and code.
I am reading your reply as adding additional process which does
not exist, and appears to be thrown-up roadblocks. I'll ignore such
attempts to introduce process until any proposed process has the
majority +1 support by the project. If others here at httpd want
to begin defining the structure of 2.6.0/3.0.0 (the next possible
GA release, because 2.5.x is not GA, by policy), I'm all for it.
It's not a prereq to begin.
http://httpd.apache.org/dev/release.html
By "vetoed tag" it does not mean you can veto a tag. That wording
means that there is no code at present which carries a veto. I'm
unaware of any code in trunk that is vetoed in the 2.5.x development
trunk branch.
Please inform within 72 hours of what you are vetoing from -alpha
examination, so that I can remove or route around it and avoid any
unnecessary tags.
The rules were designed from day 1 of the ASF as a foundation
that no one individual can block forward progress of the project,
any PMC member may branch, or tag. The majority decision of
the project decides whether that tag is adopted as a release
(even -alpha requires a majority, 3 +1's!)
As the saying goes "We won't know till we try"... let's see if we
have collectively treated trunk/ well, and whether adventurous
users on the bleeding edge like what they see.
On Mon, Oct 23, 2017 at 4:32 PM, Jim Jagielski <j...@jagunet.com>
wrote:
The issue obviously isn't in the *tagging*. It is the unknown
aspect of what is expected AFTER the tagging.
I see the tagging as simply a mechanism to force action
upon the PMC to go down a route which the PMC has not
decided, from what I can tell, to go down. Maybe I'm wrong.
But your reply tends to support that interpretation. The tag, per
se, is not the goal. The goal is to "push" 2.5.0 when, again
from what I can tell, the PMC has not decided that such
a push is warranted/needed/desired/whatever.
So if you want to tag, first generate a roadmap, that can be
shared and discussed with the PMC, and the dev community,
what that 1st step is intended to lead us to. But let's
not pretend that such tagging is simply noting a SVN revision.
You may complain that I "single handedly" do Foo and Bar
and other dictatorial and dangerous stuff, but AFAIK, I've
never done or proposed anything w/o bringing it up
to the list 1st (ala PROXY support, mod_wsgi, health
checks... etc...). Even w/ releases and tags I give
people more than 24hours notice. Unless, of course,
your tag was under Lazy Consensus, in which case my
"veto" was valid, if more "strong" than required. In
which case, I am sorry for that.
