FTR: I refuse any discussion where people, already in the initial 
statements, discuss each others merit and downfalls and whatnot.

If you want to talk about technical stuff and/or propose a project plan,
start a new thread without all that destructive crap I will not waste
any more time than this mail about.

Cheers,

Stefan

> 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.

Reply via email to