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.
