Re: [RESULT] Was Re: [VOTE] Back to ASF Basics (Was: Re: Review model take 2)
Hi, I vote +1 :-) Peter Am 26.09.2007 um 16:22 schrieb Jim Jagielski: I'd like to call a vote on acceptance of the above methodology, as crafted and fine-tuned by Costin and myself. It is worthwhile to note that, really, these are the typical ASF methods, but with some "grainy" aspects better defined. In essence, some typical "niceties" are now mandated (changes, even in CTR, which affect the API, must be brought up first to gauge community approval). [ ] +1. Yes, the above works and addresses my concerns as well as the problems which started this whole thing. [ ] 0. Whatever. [ ] -1. The above does not work for the following reasons: The vote will run for 96 hours instead of the normal 72 because of the weekend. Only binding votes will be counted, but non-binding votes will be used to address wider concern/acceptance of the proposal. Looks like the 96 hours are up, and the tally is: +1: jim, yoav, tim, remy, costin, filip, mark, mladen, jean-frederic, rainer Not Sure: Peter followed up: "I agree with Remy: We must find a process that really work normally quick and can handle conflicts fair." Henri +1'ed Peter's post. So I am not sure if Peter actually cast a vote or simply made a comment and I'm not sure if Henri +1'ed the proposal or Peter's comment or both. -1: null set As such, the vote passes!! We can now give ourselves a pat on the back for resolving this and start implementing the changes we approved... - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [RESULT] Was Re: [VOTE] Back to ASF Basics (Was: Re: Review model take 2)
[ ] +1. Yes, the above works and addresses my concerns as well as the problems which started this whole thing. Just to be sure 2007/9/26, Jim Jagielski <[EMAIL PROTECTED]>: > > > I'd like to call a vote on acceptance of the above methodology, > > as crafted and fine-tuned by Costin and myself. It is worthwhile > > to note that, really, these are the typical ASF methods, but > > with some "grainy" aspects better defined. In essence, some > > typical "niceties" are now mandated (changes, even in CTR, which > > affect the API, must be brought up first to gauge community > > approval). > > > >[ ] +1. Yes, the above works and addresses my concerns > >as well as the problems which started this whole > >thing. > >[ ] 0. Whatever. > >[ ] -1. The above does not work for the following reasons: > > > > The vote will run for 96 hours instead of the normal 72 because of > > the weekend. Only binding votes will be counted, but non-binding > > votes will be used to address wider concern/acceptance of > > the proposal. > > > > Looks like the 96 hours are up, and the tally is: > >+1: jim, yoav, tim, remy, costin, filip, mark, mladen, >jean-frederic, rainer > >Not Sure: Peter followed up: "I agree with Remy: We must find a > process > that really work normally quick and can handle > conflicts fair." Henri +1'ed Peter's post. So I am > not sure if Peter actually cast a vote or simply made > a comment and I'm not sure if Henri +1'ed the proposal > or Peter's comment or both. > -1: null set > > As such, the vote passes!! > > We can now give ourselves a pat on the back for resolving this > and start implementing the changes we approved... > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[RESULT] Was Re: [VOTE] Back to ASF Basics (Was: Re: Review model take 2)
I'd like to call a vote on acceptance of the above methodology, as crafted and fine-tuned by Costin and myself. It is worthwhile to note that, really, these are the typical ASF methods, but with some "grainy" aspects better defined. In essence, some typical "niceties" are now mandated (changes, even in CTR, which affect the API, must be brought up first to gauge community approval). [ ] +1. Yes, the above works and addresses my concerns as well as the problems which started this whole thing. [ ] 0. Whatever. [ ] -1. The above does not work for the following reasons: The vote will run for 96 hours instead of the normal 72 because of the weekend. Only binding votes will be counted, but non-binding votes will be used to address wider concern/acceptance of the proposal. Looks like the 96 hours are up, and the tally is: +1: jim, yoav, tim, remy, costin, filip, mark, mladen, jean-frederic, rainer Not Sure: Peter followed up: "I agree with Remy: We must find a process that really work normally quick and can handle conflicts fair." Henri +1'ed Peter's post. So I am not sure if Peter actually cast a vote or simply made a comment and I'm not sure if Henri +1'ed the proposal or Peter's comment or both. -1: null set As such, the vote passes!! We can now give ourselves a pat on the back for resolving this and start implementing the changes we approved... - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Back to ASF Basics (Was: Re: Review model take 2)
jean-frederic clere wrote: > Mark Thomas wrote: >> Jim Jagielski wrote: >> >> - There is only one dev branch. I am -1 for creating separate dev >> branches for 3.3.x, 4.1.x, 5.0.x and 5.5.x on the grounds it is too much >> overhead for branches that are in maintenance mode where 99% of the >> patches will be ported from 6.x > > Apache httpd works that way. In case a patch can't fit in mail use > people.apache.org to store the patch to review. What we typically do at httpd; 1. Patch trunk (CTR). 2. Prepare patches to desired release branches to which the trunk commit diff wouldn't apply cleanly, with a minimum of fuzz. 3. Propose a backport to current release branch(es) (e.g. to version n.n, n.n-1, n.n-2 etc). This happens in each released branches' STATUS file. 4. Wait to collect 3+1's. Compensate for any objections in the meantime. Sometimes, withdraw the backport proposal and jump back to step 1. above and proceed with a fresh patch. How far back that goes depends on how broad the bug was, if it represents a fix or new feature, how ABI neutral the change is, etc. There is one especially nice side effect. Rather than waiting for the release of the next version to review; the trunk changes which are proposed for backport get extra scrutiny while they are fresh in the contributors' mind. (How many of us have had to reconstruct why we choose to do something in a specific manner, months or years later, before +1'ing a suggested change to the code we wrote?) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Back to ASF Basics (Was: Re: Review model take 2)
+1 2007/9/23, Peter Rossbach <[EMAIL PROTECTED]>: > >>>[X] +1. Yes, the above works and addresses my concerns > >>>as well as the problems which started this whole > >>>thing. > >>>[ ] 0. Whatever. > >>>[ ] -1. The above does not work for the following reasons: > > I agree with Remy: We must find a process that really work normally > quick and > can handle conflicts fair. > > Peter > > > Am 23.09.2007 um 11:09 schrieb Remy Maucherat: > > > Mark Thomas wrote: > >> Jim Jagielski wrote: > >>> > >>> > >> With the following caveats: > >> - There is only one dev branch. I am -1 for creating separate dev > >> branches for 3.3.x, 4.1.x, 5.0.x and 5.5.x on the grounds it is > >> too much > >> overhead for branches that are in maintenance mode where 99% of the > >> patches will be ported from 6.x > >> - Where a patch for 3, 4 or 5 is required that just doesn't make > >> sense > >> in the dev branch then the patch is applied using RTC. > >> - We review this process in 3 months time to see if it is > >> providing the > >> expected benefits without excessive overheads. > >> - We improve the "Which version?" web page to make clear which > >> branches > >> are supported and at what level. I'll start a wiki page as a draft > >> of this. > >> - The "Get involved" pages are updated to document this process > > > > Some points of my own: > > - I think my proposed process was more adapted to the Tomcat situation > > - The way Jim rushed his vote seems to shortcut any possibility of > > me to present a vote at the moment (which is fairly annoying as I > > spent weeks discussing details and integrating changes) > > - I am not aware of any ASF rule specifying that a project cannot > > define its own release process > > > > Since it does most of what I suggested and there was no "this will > > not be changeable through further discussions and votes", I did > > vote in favor of it. I would be willing to revisit it later since I > > doubt it is well suited to the size of the Tomcat community and the > > way it works. > > > > Rémy > > > > - > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Back to ASF Basics (Was: Re: Review model take 2)
[X] +1. Yes, the above works and addresses my concerns as well as the problems which started this whole thing. [ ] 0. Whatever. [ ] -1. The above does not work for the following reasons: I agree with Remy: We must find a process that really work normally quick and can handle conflicts fair. Peter Am 23.09.2007 um 11:09 schrieb Remy Maucherat: Mark Thomas wrote: Jim Jagielski wrote: With the following caveats: - There is only one dev branch. I am -1 for creating separate dev branches for 3.3.x, 4.1.x, 5.0.x and 5.5.x on the grounds it is too much overhead for branches that are in maintenance mode where 99% of the patches will be ported from 6.x - Where a patch for 3, 4 or 5 is required that just doesn't make sense in the dev branch then the patch is applied using RTC. - We review this process in 3 months time to see if it is providing the expected benefits without excessive overheads. - We improve the "Which version?" web page to make clear which branches are supported and at what level. I'll start a wiki page as a draft of this. - The "Get involved" pages are updated to document this process Some points of my own: - I think my proposed process was more adapted to the Tomcat situation - The way Jim rushed his vote seems to shortcut any possibility of me to present a vote at the moment (which is fairly annoying as I spent weeks discussing details and integrating changes) - I am not aware of any ASF rule specifying that a project cannot define its own release process Since it does most of what I suggested and there was no "this will not be changeable through further discussions and votes", I did vote in favor of it. I would be willing to revisit it later since I doubt it is well suited to the size of the Tomcat community and the way it works. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Back to ASF Basics (Was: Re: Review model take 2)
Jim Jagielski schrieb: >[X] +1. Yes, the above works and addresses my concerns >as well as the problems which started this whole >thing. >[ ] 0. Whatever. >[ ] -1. The above does not work for the following reasons: - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Back to ASF Basics (Was: Re: Review model take 2)
Mark Thomas wrote: > > Jim Jagielski wrote: > >[X] +1. Yes, the above works and addresses my concerns > >as well as the problems which started this whole > >thing. > >[ ] 0. Whatever. > >[ ] -1. The above does not work for the following reasons: > > > > With the following caveats: > > - There is only one dev branch. I am -1 for creating separate dev > branches for 3.3.x, 4.1.x, 5.0.x and 5.5.x on the grounds it is too much > overhead for branches that are in maintenance mode where 99% of the > patches will be ported from 6.x > > - Where a patch for 3, 4 or 5 is required that just doesn't make sense > in the dev branch then the patch is applied using RTC. > > - We review this process in 3 months time to see if it is providing the > expected benefits without excessive overheads. > > - We improve the "Which version?" web page to make clear which branches > are supported and at what level. I'll start a wiki page as a draft of this. > > - The "Get involved" pages are updated to document this process FWIW, under httpd there is not a 1.3 dev/release branch pair, nor is there "really" one for 2.0. So No, I don't think that such a pair is required for any codebase which is in maint mode, just for those undergoing active development. -- === Jim Jagielski [|] [EMAIL PROTECTED] [|] http://www.jaguNET.com/ "If you can dodge a wrench, you can dodge a ball." - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Back to ASF Basics (Was: Re: Review model take 2)
Mladen Turk wrote: > > Jim Jagielski wrote: > > > > > >[X] +1. Yes, the above works and addresses my concerns > >as well as the problems which started this whole > >thing. > >[ ] 0. Whatever. > >[ ] -1. The above does not work for the following reasons: > > > > If voted (and it looks it will) we should put them somewhere > for easier future reference. > I already proposed > http://tomcat.apache.org/getinvolved.html or > http://tomcat.apache.org/svn.html > ++1 > Regards, > Mladen > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > -- === Jim Jagielski [|] [EMAIL PROTECTED] [|] http://www.jaguNET.com/ "If you can dodge a wrench, you can dodge a ball." - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Back to ASF Basics (Was: Re: Review model take 2)
Mark Thomas wrote: > Jim Jagielski wrote: >>[X] +1. Yes, the above works and addresses my concerns >>as well as the problems which started this whole >>thing. >>[ ] 0. Whatever. >>[ ] -1. The above does not work for the following reasons: >> > > With the following caveats: > > - There is only one dev branch. I am -1 for creating separate dev > branches for 3.3.x, 4.1.x, 5.0.x and 5.5.x on the grounds it is too much > overhead for branches that are in maintenance mode where 99% of the > patches will be ported from 6.x Apache httpd works that way. In case a patch can't fit in mail use people.apache.org to store the patch to review. Note that tomcat/tc6.0.x/ is a released branche and it should be RTC too. Cheers Jean-Frederic > > - Where a patch for 3, 4 or 5 is required that just doesn't make sense > in the dev branch then the patch is applied using RTC. > > - We review this process in 3 months time to see if it is providing the > expected benefits without excessive overheads. > > - We improve the "Which version?" web page to make clear which branches > are supported and at what level. I'll start a wiki page as a draft of this. > > - The "Get involved" pages are updated to document this process > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Back to ASF Basics (Was: Re: Review model take 2)
+1 Cheers Jean-Frederic > >[ ] +1. Yes, the above works and addresses my concerns >as well as the problems which started this whole >thing. >[ ] 0. Whatever. >[ ] -1. The above does not work for the following reasons: > > The vote will run for 96 hours instead of the normal 72 because of > the weekend. Only binding votes will be counted, but non-binding > votes will be used to address wider concern/acceptance of > the proposal. > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Back to ASF Basics (Was: Re: Review model take 2)
Mark Thomas wrote: Jim Jagielski wrote: [X] +1. Yes, the above works and addresses my concerns as well as the problems which started this whole thing. [ ] 0. Whatever. [ ] -1. The above does not work for the following reasons: With the following caveats: - There is only one dev branch. I am -1 for creating separate dev branches for 3.3.x, 4.1.x, 5.0.x and 5.5.x on the grounds it is too much overhead for branches that are in maintenance mode where 99% of the patches will be ported from 6.x - Where a patch for 3, 4 or 5 is required that just doesn't make sense in the dev branch then the patch is applied using RTC. - We review this process in 3 months time to see if it is providing the expected benefits without excessive overheads. - We improve the "Which version?" web page to make clear which branches are supported and at what level. I'll start a wiki page as a draft of this. - The "Get involved" pages are updated to document this process Some points of my own: - I think my proposed process was more adapted to the Tomcat situation - The way Jim rushed his vote seems to shortcut any possibility of me to present a vote at the moment (which is fairly annoying as I spent weeks discussing details and integrating changes) - I am not aware of any ASF rule specifying that a project cannot define its own release process Since it does most of what I suggested and there was no "this will not be changeable through further discussions and votes", I did vote in favor of it. I would be willing to revisit it later since I doubt it is well suited to the size of the Tomcat community and the way it works. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Back to ASF Basics (Was: Re: Review model take 2)
Jim Jagielski wrote: [X] +1. Yes, the above works and addresses my concerns as well as the problems which started this whole thing. [ ] 0. Whatever. [ ] -1. The above does not work for the following reasons: If voted (and it looks it will) we should put them somewhere for easier future reference. I already proposed http://tomcat.apache.org/getinvolved.html or http://tomcat.apache.org/svn.html Regards, Mladen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Back to ASF Basics (Was: Re: Review model take 2)
Jim Jagielski wrote: >[X] +1. Yes, the above works and addresses my concerns >as well as the problems which started this whole >thing. >[ ] 0. Whatever. >[ ] -1. The above does not work for the following reasons: > With the following caveats: - There is only one dev branch. I am -1 for creating separate dev branches for 3.3.x, 4.1.x, 5.0.x and 5.5.x on the grounds it is too much overhead for branches that are in maintenance mode where 99% of the patches will be ported from 6.x - Where a patch for 3, 4 or 5 is required that just doesn't make sense in the dev branch then the patch is applied using RTC. - We review this process in 3 months time to see if it is providing the expected benefits without excessive overheads. - We improve the "Which version?" web page to make clear which branches are supported and at what level. I'll start a wiki page as a draft of this. - The "Get involved" pages are updated to document this process - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Back to ASF Basics (Was: Re: Review model take 2)
Jim Jagielski wrote: Remy Maucherat wrote: Jim Jagielski wrote: [X] +1. Yes, the above works and addresses my concerns as well as the problems which started this whole thing. [ ] 0. Whatever. [ ] -1. The above does not work for the following reasons: My proposal was to put the principles forward clearly: - core changes need to be discussed beforehand - calls for review (or vetoes, which in the end are sometimes very similar) should be considered rather than exclusively spend time to determine if they are legitimate See the bulleted EMail which was in response to Tim's request :) I thought paraphrasing a little bit would not hurt, and it explains my vote. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Back to ASF Basics (Was: Re: Review model take 2)
Remy Maucherat wrote: > > Jim Jagielski wrote: > >[X] +1. Yes, the above works and addresses my concerns > >as well as the problems which started this whole > >thing. > >[ ] 0. Whatever. > >[ ] -1. The above does not work for the following reasons: > > My proposal was to put the principles forward clearly: > - core changes need to be discussed beforehand > - calls for review (or vetoes, which in the end are sometimes very > similar) should be considered rather than exclusively spend time to > determine if they are legitimate > See the bulleted EMail which was in response to Tim's request :) -- === Jim Jagielski [|] [EMAIL PROTECTED] [|] http://www.jaguNET.com/ "If you can dodge a wrench, you can dodge a ball." - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Back to ASF Basics (Was: Re: Review model take 2)
Jim Jagielski wrote: [X] +1. Yes, the above works and addresses my concerns as well as the problems which started this whole thing. [ ] 0. Whatever. [ ] -1. The above does not work for the following reasons: The vote will run for 96 hours instead of the normal 72 because of the weekend. Only binding votes will be counted, but non-binding votes will be used to address wider concern/acceptance of the proposal. Filip - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Back to ASF Basics (Was: Re: Review model take 2)
+1 On 9/22/07, Jim Jagielski <[EMAIL PROTECTED]> wrote: > > On Sep 22, 2007, at 9:45 AM, Jim Jagielski wrote: > > > > >[X] +1. Yes, the above works and addresses my concerns > >as well as the problems which started this whole > >thing. > >[ ] 0. Whatever. > >[ ] -1. The above does not work for the following reasons: > > > > The vote will run for 96 hours instead of the normal 72 because of > > the weekend. Only binding votes will be counted, but non-binding > > votes will be used to address wider concern/acceptance of > > the proposal. > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Back to ASF Basics (Was: Re: Review model take 2)
this email is so unclean, I'm a bit confused on the exact bullets, mind posting a new thread? Filip Jim Jagielski wrote: On Sep 21, 2007, at 4:36 PM, Jim Jagielski wrote: On Sep 21, 2007, at 4:27 PM, Costin Manolache wrote: On 9/21/07, Jim Jagielski <[EMAIL PROTECTED]> wrote: Just propose a polite way to move from the commit for a controversial change ( i.e. when someone feels strongly it's going to the wrong direction, even if technically code is ok ) to the majority and 3+1 process - and we're done. As you know - some people are complaining that veto is abused ( and that's right ), many Rs turn into flame wars and get personal - so the issue is how to avoid a technical code discussion for a non-technical or subjective issue. First, it's important to recall that whether under CTR or RTC, there is always Review. If people, after something has been committed under CTR has issues with it, then that is Reviewing it after all. We already discussed technical voting, but what about "direction" or "vision" review. Or, as you said in a previous Email: ... a polite way of saying: "Hey, nothing wrong with the code itself, but I don't think there is enough support from the community for the direction you're going - could you confirm that a majority and at least 3 people think it fits our goals ?" That's still part of the review process... Vetoes are there to prevent code from being committed, but not all reviews are for the functional aspects of the actual code but rather to determine how much support there is for an implementation or feature... So I would say that this is still a valid and expected part of the R in *both* CTR and RTC. The thing is, of course, one cannot veto code based on non-technical reasons, but one can certainly review it based on such reasons and ask for some guidance that it makes sense. IMO, most of those types of cases should fall into the following types: 1. People who agree and will help support it, implement it, etc... (+1) 2. People who don't care one way or another. (+0) 3. People who don't like it, but hey, if it helps you out and there are other people behind it, I won't stand in your way. (-0.9) 4. I don't like it and this is why. It would be a mistake. (-1) +1 If possible, add 5 and 6: 5. I may like it, but as a module that is not enabled by default. 6. I may like it, but as a standalone module, easy to download and install, but not bundled in the base distro. Assuming some sort of module impl exists, yes, of course. Both 5 and 6 should be counted as -0.9 on the change itself, but as +0.9 if the concern is addressed. Yes, if everyone understand this - and we stop using early commit/lazy consensus and veto to get around R by a larger set of people - big +1. I like CTR and having an official trunk where active development happens - but I don't like the endless discussion about veto validity and some big changes made without consensus or consultation - that was the main reason I support a partial RTC until people get used to the idea of getting a +3 for important changes. Costin I think all this handles the obvious and some of the non-obvious holes that had been in place... I'd like to call a vote on acceptance of the above methodology, as crafted and fine-tuned by Costin and myself. It is worthwhile to note that, really, these are the typical ASF methods, but with some "grainy" aspects better defined. In essence, some typical "niceties" are now mandated (changes, even in CTR, which affect the API, must be brought up first to gauge community approval). [ ] +1. Yes, the above works and addresses my concerns as well as the problems which started this whole thing. [ ] 0. Whatever. [ ] -1. The above does not work for the following reasons: The vote will run for 96 hours instead of the normal 72 because of the weekend. Only binding votes will be counted, but non-binding votes will be used to address wider concern/acceptance of the proposal. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Back to ASF Basics (Was: Re: Review model take 2)
Jim Jagielski wrote: [X] +1. Yes, the above works and addresses my concerns as well as the problems which started this whole thing. [ ] 0. Whatever. [ ] -1. The above does not work for the following reasons: My proposal was to put the principles forward clearly: - core changes need to be discussed beforehand - calls for review (or vetoes, which in the end are sometimes very similar) should be considered rather than exclusively spend time to determine if they are legitimate [Your proposal generally has more constraints and is identical to Jean-Frédéric rejected proposal; great, thanks a lot :) My only (minor) reservation is the lack of real criterion for determining which patch should be discussed beforehand or put to review in the development branch, which creates a room for interpretation, hence some "artistic" feeling.] Since you brought forward this reasonable compromise vote, I vote in favor of it. I will trust you to monitor the Tomcat project in the future [since you've apparently decided to increase your involvement in the project] to see that this is properly respected. Anyway, thanks a lot for your decision and involvement. I trust you to see how to help resolve the little "differences" I have with Filip now :) Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Back to ASF Basics (Was: Re: Review model take 2)
Jim Jagielski wrote: [X] +1. Yes, the above works and addresses my concerns as well as the problems which started this whole thing. [ ] 0. Whatever. [ ] -1. The above does not work for the following reasons: - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Back to ASF Basics (Was: Re: Review model take 2)
Here is the synopsis:
o Existence of release and development branches
in parallel with each other (dev are odd numbered,
release are even numbered).
o Development branches are CTR. If code or patches
to this branch change the API, advanced warning
is required even before the commit. It may be
open to a vote if there is debate. Larger patches,
as well as far-reaching patches should also be
community gauged before implemented.
o Release branches are RTC, with patches obtained
from the development tree. Thus, backports refer
to the SVN revision on the development tree which
adds that feature.
o Both branches have a STATUS file. For the release
branch, STATUS is also used to note backport
proposals.
o Reviews are *always* appropriate. One can call
for a formal review of a patch at any time.
o Voting is via normal ASF rules.
o Regarding large and/or API changing patches, use of
a sandbox is recommended to allow for SVN history to
be maintain, to encourage outside interest and
involvement ("Hey, I'm working on Foo. Here is the
SVN url. Come and help or at least follow along").
This also allows for more complete understanding of
the impacts before it reaches the dev branch.
As previously mentioned, this is simply detailed information
about normal ASF development mechanisms, with some SVN
best practices thrown in to ease the collaborative efforts.
(The numbering in the 1st bullet is not required, of course,
but parallel dev/release branches are key. It ensures that
no code enters release without 2 review phases: the 1st
via CTR in the development branch and the 2nd via RTC
when backported to the release branch).
On Sep 22, 2007, at 1:42 PM, Tim Funk wrote:
Can we have a new VOTE with the six bullets (if it is that many -
I'm losing track with all the responses).
I'm not quite sure what I'm voting for.
-Tim
I'd like to call a vote on acceptance of the above methodology,
as crafted and fine-tuned by Costin and myself. It is worthwhile
to note that, really, these are the typical ASF methods, but
with some "grainy" aspects better defined. In essence, some
typical "niceties" are now mandated (changes, even in CTR, which
affect the API, must be brought up first to gauge community
approval).
[ ] +1. Yes, the above works and addresses my concerns
as well as the problems which started this whole
thing.
[ ] 0. Whatever.
[ ] -1. The above does not work for the following reasons:
The vote will run for 96 hours instead of the normal 72 because of
the weekend. Only binding votes will be counted, but non-binding
votes will be used to address wider concern/acceptance of
the proposal.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Back to ASF Basics (Was: Re: Review model take 2)
Can we have a new VOTE with the six bullets (if it is that many - I'm losing track with all the responses). I'm not quite sure what I'm voting for. -Tim I'd like to call a vote on acceptance of the above methodology, as crafted and fine-tuned by Costin and myself. It is worthwhile to note that, really, these are the typical ASF methods, but with some "grainy" aspects better defined. In essence, some typical "niceties" are now mandated (changes, even in CTR, which affect the API, must be brought up first to gauge community approval). [ ] +1. Yes, the above works and addresses my concerns as well as the problems which started this whole thing. [ ] 0. Whatever. [ ] -1. The above does not work for the following reasons: The vote will run for 96 hours instead of the normal 72 because of the weekend. Only binding votes will be counted, but non-binding votes will be used to address wider concern/acceptance of the proposal. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Back to ASF Basics (Was: Re: Review model take 2)
Hey, On 9/22/07, Jim Jagielski <[EMAIL PROTECTED]> wrote: > [ X ] +1. Yes, the above works and addresses my concerns > as well as the problems which started this whole > thing. Yoav - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Back to ASF Basics (Was: Re: Review model take 2)
On Sep 22, 2007, at 9:45 AM, Jim Jagielski wrote: [X] +1. Yes, the above works and addresses my concerns as well as the problems which started this whole thing. [ ] 0. Whatever. [ ] -1. The above does not work for the following reasons: The vote will run for 96 hours instead of the normal 72 because of the weekend. Only binding votes will be counted, but non-binding votes will be used to address wider concern/acceptance of the proposal. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[VOTE] Back to ASF Basics (Was: Re: Review model take 2)
On Sep 21, 2007, at 4:36 PM, Jim Jagielski wrote: On Sep 21, 2007, at 4:27 PM, Costin Manolache wrote: On 9/21/07, Jim Jagielski <[EMAIL PROTECTED]> wrote: Just propose a polite way to move from the commit for a controversial change ( i.e. when someone feels strongly it's going to the wrong direction, even if technically code is ok ) to the majority and 3+1 process - and we're done. As you know - some people are complaining that veto is abused ( and that's right ), many Rs turn into flame wars and get personal - so the issue is how to avoid a technical code discussion for a non-technical or subjective issue. First, it's important to recall that whether under CTR or RTC, there is always Review. If people, after something has been committed under CTR has issues with it, then that is Reviewing it after all. We already discussed technical voting, but what about "direction" or "vision" review. Or, as you said in a previous Email: ... a polite way of saying: "Hey, nothing wrong with the code itself, but I don't think there is enough support from the community for the direction you're going - could you confirm that a majority and at least 3 people think it fits our goals ?" That's still part of the review process... Vetoes are there to prevent code from being committed, but not all reviews are for the functional aspects of the actual code but rather to determine how much support there is for an implementation or feature... So I would say that this is still a valid and expected part of the R in *both* CTR and RTC. The thing is, of course, one cannot veto code based on non-technical reasons, but one can certainly review it based on such reasons and ask for some guidance that it makes sense. IMO, most of those types of cases should fall into the following types: 1. People who agree and will help support it, implement it, etc... (+1) 2. People who don't care one way or another. (+0) 3. People who don't like it, but hey, if it helps you out and there are other people behind it, I won't stand in your way. (-0.9) 4. I don't like it and this is why. It would be a mistake. (-1) +1 If possible, add 5 and 6: 5. I may like it, but as a module that is not enabled by default. 6. I may like it, but as a standalone module, easy to download and install, but not bundled in the base distro. Assuming some sort of module impl exists, yes, of course. Both 5 and 6 should be counted as -0.9 on the change itself, but as +0.9 if the concern is addressed. Yes, if everyone understand this - and we stop using early commit/ lazy consensus and veto to get around R by a larger set of people - big +1. I like CTR and having an official trunk where active development happens - but I don't like the endless discussion about veto validity and some big changes made without consensus or consultation - that was the main reason I support a partial RTC until people get used to the idea of getting a +3 for important changes. Costin I think all this handles the obvious and some of the non-obvious holes that had been in place... I'd like to call a vote on acceptance of the above methodology, as crafted and fine-tuned by Costin and myself. It is worthwhile to note that, really, these are the typical ASF methods, but with some "grainy" aspects better defined. In essence, some typical "niceties" are now mandated (changes, even in CTR, which affect the API, must be brought up first to gauge community approval). [ ] +1. Yes, the above works and addresses my concerns as well as the problems which started this whole thing. [ ] 0. Whatever. [ ] -1. The above does not work for the following reasons: The vote will run for 96 hours instead of the normal 72 because of the weekend. Only binding votes will be counted, but non-binding votes will be used to address wider concern/acceptance of the proposal. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
