Re: Why tag 2.5.0? [Was: Re: Tagging 2.4.29 / 2.5.0-{alpha/beta?} today]
On Tue, Oct 24, 2017 at 3:12 AM, Stefan Eissing wrote: > 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. That's exactly what I did; On Fri, Oct 13, 2017 at 8:19 AM, William A Rowe Jr wrote: > Is anyone seeing an issue of concern about stability on 2.4.x branch? > > Has anyone else looked at Jim's proposed fixes for xcode 9 building > under maintainer mode? A couple-line quick fix to configure.in, that > anyone on OS/X should be able to validate in minutes. The same fix > is already present on APR's branches, which I will tag as well. > > I'll proceed to tag 2.5.0, and 2.4.29 after a couple hour comment > period, so that the many proposed enhancements can be examined > by alpha testers and our quick adopters of 2.4.28 can be back on track > by early next week. That should simplify getting some of the more > complex patches backported as necessary, or move us forward > in any case. There was no animus or personality involved in this statement. Follow the thread to find out where it "broke" and who broke it. I will kill this thread; I should have limited it to responding that our ruleset inhibits vetoes of tags and releases; then a second fresh thread not to anyone's comment in particular explaining the basis of 2.5.0-alpha. My bad, I apologize for mixing the two, and will more carefully avoid this in the future.
Re: Re: Why tag 2.5.0? [Was: Re: Tagging 2.4.29 / 2.5.0-{alpha/beta?}today]
wrong link where to clean up: http://svn.apache.org/viewvc/httpd/httpd/branches/ On Tuesday 24/10/2017 at 10:26, Steffen wrote: Can someone clean up the not needed anymore backports/branches at http://svn.apache.org/viewvc/httpd/httpd/branches/?sortby=date On Tuesday 24/10/2017 at 10:12, Stefan Eissing wrote: 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 : 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 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.
Re: Why tag 2.5.0? [Was: Re: Tagging 2.4.29 / 2.5.0-{alpha/beta?}today]
Can someone clean up the not needed anymore backports/branches at http://svn.apache.org/viewvc/httpd/httpd/branches/?sortby=date On Tuesday 24/10/2017 at 10:12, Stefan Eissing wrote: 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 : 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 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.
Re: Why tag 2.5.0? [Was: Re: Tagging 2.4.29 / 2.5.0-{alpha/beta?} today]
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 : > > 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 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.
Re: Why tag 2.5.0? [Was: Re: Tagging 2.4.29 / 2.5.0-{alpha/beta?} today]
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 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.
Re: Why tag 2.5.0? [Was: Re: Tagging 2.4.29 / 2.5.0-{alpha/beta?} today]
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.
