You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by Remy Maucherat <re...@apache.org> on 2007/09/18 19:54:35 UTC
Review model take 2
Hi,
Another more precise draft.
Patches which would go to review would be:
- API changing patches (any protected or above signature change) on APIs
which are accessible to the user either from confirguration or
programmatically
- any other commit for which a committer asks for the RTC procedure
should be rollbacked if it hinders concurrent work or is to be included
in a release tag, and go through the RTC procedure
The RTC procedure would include a STATUS file in the Tomcat svn listing
all pending "up to review" changes. A successful vote with a +3 margin
is required. A patch can remain under review for as long as the
committer wishes, and it should be allowed to freely "advertise" and
discuss the vote.
The idea would be to force a consensus for commits which could have
significant implications, and help stage technical discussions (rather
than discussions about the validity of the disagreement). It would
introduce a small delay for committing certain patches and a minor
slowdown for development pace in theory, but in practice I've noticed
conflicts waste a lot more time.
This would also mean it is possible to make a change that a number of
committers oppose (possibly, would veto) if enough committers are in
favor of it.
Rémy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Review model take 2
Posted by Yoav Shapira <yo...@apache.org>.
Hey,
On 9/18/07, Remy Maucherat <re...@apache.org> wrote:
> Another more precise draft.
<snip />
> than discussions about the validity of the disagreement). It would
> introduce a small delay for committing certain patches and a minor
> slowdown for development pace in theory, but in practice I've noticed
> conflicts waste a lot more time.
>
> This would also mean it is possible to make a change that a number of
> committers oppose (possibly, would veto) if enough committers are in
> favor of it.
I agree on both counts, and this seems like a very reasonable
compromise process.
+1
Yoav
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Review model take 2
Posted by Tim Funk <fu...@joedog.org>.
+1
-Tim
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Review model take 2
Posted by Filip Hanik - Dev Lists <de...@hanik.com>.
Jim Jagielski wrote:
>
> On Sep 21, 2007, at 1:59 PM, Jim Jagielski wrote:
>
>>
>> All good points. It just seems to me that the voting should be
>> on code that, as you said, affects people. When the code enters
>> a release branch, then approval is needed. The fact that it's
>> been in trunk and has worked well and that others within
>> the PMC and dev community have played and worked with it
>> will count for something, but it is still a RTC rule. Having
>> trunk means we get consensus twice: the 1st under CTR (a lazy
>> consensus to be sure) and then when moved to release under
>> RTC.
>>
>
> And again, what we are talking about is not that much
> different from Remy's proposal:
>
> Remy's proposal is:
>
> Patches which would go to review would be:
> - API changing patches (any protected or above signature change) on
> APIs which are accessible to the user either from confirguration or
> programmatically
> - any other commit for which a committer asks for the RTC procedure
> should be rollbacked if it hinders concurrent work or is to be
> included in a release tag, and go through the RTC procedure
>
> The RTC procedure would include a STATUS file in the Tomcat svn
> listing all pending "up to review" changes. A successful vote with a
> +3 margin is required. A patch can remain under review for as long as
> the committer wishes, and it should be allowed to freely "advertise"
> and discuss the vote.
>
> If we simply say this is for release branches (X.Y where Y is even) then
> we pretty much just have RTC, since simple patches will get the required
> 3 +1 votes pretty quickly). In fact, Remy's comment "to be included
> in a release tag" pretty much makes it clear that what is the
> concern is what is released (the "affects other people" rule).
>
> If we have a trunk which is CTR, then we can also have a general rule
> that says "For API changes, patches should be done with advance
> notice under lazy consensus" ("I plan on doing this which will
> break/improve/modify the API. I plan on committing this in 3 days.
> Holler if you have any complaints")... which is a normal
> courtesy anyway. For really far reaching ones, people break
> off a sandbox, do their stuff there, and refer to the sandbox
> repo directory when giving the advance notice... (this is
> also good since it allows people to see the history behind
> the development as well).
>
> So I really don't see a lot of difference here...
This is what I have been trying to convey, although, much of my things
get lost in the flame debate, mostly my fault.
the difference is in the eye of the beholder, that is why I believe
going with the predefined rules that ASF already has, since going away
from that leaves too much to interpretation, and it also makes it easier
bringing in new committers, especially if they are already familiar with
the ASF.
Filip
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Review model take 2
Posted by Jim Jagielski <ji...@jaguNET.com>.
On Sep 21, 2007, at 2:46 PM, William A. Rowe, Jr. wrote:
> Jim Jagielski wrote:
>>
>> So how about this... this is something that has been done, and
>> is being done, in just about every ASF project. Why don't
>> we vote on this and give it a time-table at which point we
>> review how it's worked out over the last 3 months or so
>> and fine-tune if and as needed?
>>
>> Once we agree this is a workable implementation, we can
>> determine numbering aspects and initial code repo loads.
>
> There's a confusing aspect; what if the new proposed process/policies
> get dropping to a /dev/howitworks.html sort of document, and that
> entire document is voted on?
>
My point is that its not really new, but rather based
on what other projects are doing. The only "new" part
would be the requirement that API changes require advanced
notice and, by default, are lazy consensus. Of course
this would be for trunk, since API changes on release
branches would be normal RTC rules anyway...
http://www.apache.org/foundation/voting.html
Trunk and development branches are just SVN best practices.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Review model take 2
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
Jim Jagielski wrote:
>
> So how about this... this is something that has been done, and
> is being done, in just about every ASF project. Why don't
> we vote on this and give it a time-table at which point we
> review how it's worked out over the last 3 months or so
> and fine-tune if and as needed?
>
> Once we agree this is a workable implementation, we can
> determine numbering aspects and initial code repo loads.
There's a confusing aspect; what if the new proposed process/policies
get dropping to a /dev/howitworks.html sort of document, and that
entire document is voted on?
It sounds (for the most part) that concensus is emerging anyways, so
it shouldn't be hard to start writing it down, and limiting discussion
to a couple of sentences of that doc that people want to discuss.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Review model take 2
Posted by Jim Jagielski <ji...@jaguNET.com>.
On Sep 21, 2007, at 2:13 PM, Jim Jagielski wrote:
>
> Patches which would go to review would be:
> - API changing patches (any protected or above signature change)
> on APIs which are accessible to the user either from confirguration
> or programmatically
> - any other commit for which a committer asks for the RTC
> procedure should be rollbacked if it hinders concurrent work or is
> to be included in a release tag, and go through the RTC procedure
>
> The RTC procedure would include a STATUS file in the Tomcat svn
> listing all pending "up to review" changes. A successful vote with
> a +3 margin is required. A patch can remain under review for as
> long as the committer wishes, and it should be allowed to freely
> "advertise" and discuss the vote.
>
> If we simply say this is for release branches (X.Y where Y is even)
> then
> we pretty much just have RTC, since simple patches will get the
> required
> 3 +1 votes pretty quickly. In fact, Remy's comment "to be included
> in a release tag" pretty much makes it clear that what is the
> concern is what is released (the "affects other people" rule).
>
> If we have a trunk which is CTR, then we can also have a general rule
> that says "For API changes, patches should be done with advance
> notice under lazy consensus" ("I plan on doing this which will
> break/improve/modify the API. I plan on committing this in 3 days.
> Holler if you have any complaints")... which is a normal
> courtesy anyway. For really far reaching ones, people break
> off a sandbox, do their stuff there, and refer to the sandbox
> repo directory when giving the advance notice... (this is
> also good since it allows people to see the history behind
> the development as well).
>
So how about this... this is something that has been done, and
is being done, in just about every ASF project. Why don't
we vote on this and give it a time-table at which point we
review how it's worked out over the last 3 months or so
and fine-tune if and as needed?
Once we agree this is a workable implementation, we can
determine numbering aspects and initial code repo loads.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Review model take 2
Posted by Jim Jagielski <ji...@jaguNET.com>.
On Sep 21, 2007, at 1:59 PM, Jim Jagielski wrote:
>
> All good points. It just seems to me that the voting should be
> on code that, as you said, affects people. When the code enters
> a release branch, then approval is needed. The fact that it's
> been in trunk and has worked well and that others within
> the PMC and dev community have played and worked with it
> will count for something, but it is still a RTC rule. Having
> trunk means we get consensus twice: the 1st under CTR (a lazy
> consensus to be sure) and then when moved to release under
> RTC.
>
And again, what we are talking about is not that much
different from Remy's proposal:
Remy's proposal is:
Patches which would go to review would be:
- API changing patches (any protected or above signature change)
on APIs which are accessible to the user either from confirguration
or programmatically
- any other commit for which a committer asks for the RTC
procedure should be rollbacked if it hinders concurrent work or is to
be included in a release tag, and go through the RTC procedure
The RTC procedure would include a STATUS file in the Tomcat svn
listing all pending "up to review" changes. A successful vote with a
+3 margin is required. A patch can remain under review for as long as
the committer wishes, and it should be allowed to freely "advertise"
and discuss the vote.
If we simply say this is for release branches (X.Y where Y is even) then
we pretty much just have RTC, since simple patches will get the required
3 +1 votes pretty quickly). In fact, Remy's comment "to be included
in a release tag" pretty much makes it clear that what is the
concern is what is released (the "affects other people" rule).
If we have a trunk which is CTR, then we can also have a general rule
that says "For API changes, patches should be done with advance
notice under lazy consensus" ("I plan on doing this which will
break/improve/modify the API. I plan on committing this in 3 days.
Holler if you have any complaints")... which is a normal
courtesy anyway. For really far reaching ones, people break
off a sandbox, do their stuff there, and refer to the sandbox
repo directory when giving the advance notice... (this is
also good since it allows people to see the history behind
the development as well).
So I really don't see a lot of difference here...
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: [VOTE] Back to ASF Basics (Was: Re: Review model take 2)
Posted by Yoav Shapira <yo...@apache.org>.
Hey,
On 9/22/07, Jim Jagielski <ji...@jagunet.com> 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: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: [VOTE] Back to ASF Basics (Was: Re: Review model take 2)
Posted by Henri Gomez <he...@gmail.com>.
+1
2007/9/23, Peter Rossbach <pr...@objektpark.de>:
> >>> [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: dev-unsubscribe@tomcat.apache.org
> > For additional commands, e-mail: dev-help@tomcat.apache.org
> >
> >
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: [VOTE] Back to ASF Basics (Was: Re: Review model take 2)
Posted by Costin Manolache <co...@gmail.com>.
+1
On 9/22/07, Jim Jagielski <ji...@jagunet.com> 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: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: [RESULT] Was Re: [VOTE] Back to ASF Basics (Was: Re: Review model take 2)
Posted by Henri Gomez <he...@gmail.com>.
[ ] +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 <ji...@jagunet.com>:
>
> > 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: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: [VOTE] Back to ASF Basics (Was: Re: Review model take 2)
Posted by Jim Jagielski <ji...@jaguNET.com>.
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: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: [VOTE] Back to ASF Basics (Was: Re: Review model take 2)
Posted by Remy Maucherat <re...@apache.org>.
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: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: [VOTE] Back to ASF Basics (Was: Re: Review model take 2)
Posted by Jim Jagielski <ji...@jaguNET.com>.
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 [|] jim@jaguNET.com [|] http://www.jaguNET.com/
"If you can dodge a wrench, you can dodge a ball."
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: [VOTE] Back to ASF Basics (Was: Re: Review model take 2)
Posted by Remy Maucherat <re...@apache.org>.
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: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: [VOTE] Back to ASF Basics (Was: Re: Review model take 2)
Posted by jean-frederic clere <jf...@gmail.com>.
+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: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: [VOTE] Back to ASF Basics (Was: Re: Review model take 2)
Posted by Filip Hanik - Dev Lists <de...@hanik.com>.
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: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: [VOTE] Back to ASF Basics (Was: Re: Review model take 2)
Posted by Peter Rossbach <pr...@objektpark.de>.
>>> [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: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
>
Re: [VOTE] Back to ASF Basics (Was: Re: Review model take 2)
Posted by Remy Maucherat <re...@apache.org>.
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: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: [VOTE] Back to ASF Basics (Was: Re: Review model take 2)
Posted by Jim Jagielski <ji...@jaguNET.com>.
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: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
--
===========================================================================
Jim Jagielski [|] jim@jaguNET.com [|] http://www.jaguNET.com/
"If you can dodge a wrench, you can dodge a ball."
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: [VOTE] Back to ASF Basics (Was: Re: Review model take 2)
Posted by Mladen Turk <mt...@apache.org>.
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: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: [VOTE] Back to ASF Basics (Was: Re: Review model take 2)
Posted by Jim Jagielski <ji...@jaguNET.com>.
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: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: [VOTE] Back to ASF Basics (Was: Re: Review model take 2)
Posted by Tim Funk <fu...@joedog.org>.
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: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: [VOTE] Back to ASF Basics (Was: Re: Review model take 2)
Posted by Filip Hanik - Dev Lists <de...@hanik.com>.
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 <ji...@jagunet.com> 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: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: [VOTE] Back to ASF Basics (Was: Re: Review model take 2)
Posted by Rainer Jung <rj...@apache.org>.
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: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: [VOTE] Back to ASF Basics (Was: Re: Review model take 2)
Posted by Tim Funk <fu...@joedog.org>.
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: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: [RESULT] Was Re: [VOTE] Back to ASF Basics (Was: Re: Review model take 2)
Posted by Peter Rossbach <pr...@objektpark.de>.
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: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
>
[RESULT] Was Re: [VOTE] Back to ASF Basics (Was: Re: Review model take 2)
Posted by Jim Jagielski <ji...@jaguNET.com>.
> 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: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: [VOTE] Back to ASF Basics (Was: Re: Review model take 2)
Posted by Jim Jagielski <ji...@jaguNET.com>.
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 [|] jim@jaguNET.com [|] http://www.jaguNET.com/
"If you can dodge a wrench, you can dodge a ball."
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: [VOTE] Back to ASF Basics (Was: Re: Review model take 2)
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
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: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: [VOTE] Back to ASF Basics (Was: Re: Review model take 2)
Posted by jean-frederic clere <jf...@gmail.com>.
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: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: [VOTE] Back to ASF Basics (Was: Re: Review model take 2)
Posted by Mark Thomas <ma...@apache.org>.
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: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
[VOTE] Back to ASF Basics (Was: Re: Review model take 2)
Posted by Jim Jagielski <ji...@jaguNET.com>.
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 <ji...@jagunet.com> 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: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Review model take 2
Posted by Jim Jagielski <ji...@jaguNET.com>.
On Sep 21, 2007, at 4:27 PM, Costin Manolache wrote:
> On 9/21/07, Jim Jagielski <ji...@jagunet.com> 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...
Should we call a vote?? Or just assume lazy consensus?
*duck*
PS: That was *a joke* ! :)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Review model take 2
Posted by Costin Manolache <co...@gmail.com>.
On 9/21/07, Jim Jagielski <ji...@jagunet.com> 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.
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
Re: Review model take 2
Posted by Jim Jagielski <ji...@jaguNET.com>.
On Sep 21, 2007, at 3:49 PM, Costin Manolache wrote:
>
> Certainly the rest of the community out there in addition to the
>> PMC determines a lot of that. In which point, I think the
>> majority would rule.
>
>
> Then I guess we are in agreement :-)
>
woo hoo!
> 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)
So when voting, one would count up the number of +1s and -1s
and see who wins. The proposal can be changed to address
deficiencies and another vote called if need be, after all
we want to achieve more universal consensus. Some places
say "As long as you have 3 people behind this, then go
for it", which implies most people are therefore in the
+0 or -0.9 and no one feels so strongly about it that
they vote a -1. But again, the -1 is not a veto per se,
since it's not technical merit being discussed or
voted on, but rather community support.
Again, the ASF voting rules kind of address this already...
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Review model take 2
Posted by Costin Manolache <co...@gmail.com>.
On 9/21/07, Jim Jagielski <ji...@jagunet.com> wrote:
>
>
> On Sep 21, 2007, at 3:10 PM, Costin Manolache wrote:
>
> >
> > Let's assume CTR ( lazy consensus - i.e. assume everyone agrees ) - what
> if it
> > turns that the consensus is lacking, not on the technical validity of
> the
Certainly the rest of the community out there in addition to the
> PMC determines a lot of that. In which point, I think the
> majority would rule.
Then I guess we are in agreement :-)
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.
Costin
Re: Review model take 2
Posted by Jim Jagielski <ji...@jaguNET.com>.
On Sep 21, 2007, at 3:10 PM, Costin Manolache wrote:
>
> Let's assume CTR ( lazy consensus - i.e. assume everyone agrees ) -
> what if
> it
> turns that the consensus is lacking, not on the technical validity
> of the
> change
> but on weather a particular change is the right direction. Should
> tomcat
> bundle the
> CGI / SSI support - or have a smaller set of feature in the base,
> like jetty
> ? NIO or apr ?
> Keep backward compat or fix major problems - and what's the middle
> line ?
>
Certainly the rest of the community out there in addition to the
PMC determines a lot of that. In which point, I think the
majority would rule.
> sides. And if 2 people have different opinion on an API in the
> trunck -
> first to make the change
> that can't be vetoed, or gives up in the flame war - wins.
>
Again, majority would rule.
All this is certainly not unique in any way to Tomcat.
Does anyone really think that developers in every other
ASF project, or any other project, don't have disagreements
or differing views of direction or implementation??
But this is about *collaborative, communal* development.
If unanimous consensus can't be reached, then majority
rules and we go on from there.
All this requires an active and attentive developer community
that makes up its own mind... I don't think anyone can argue that
we don't have that now :)
> API and big, long term changes and the direction of the project
> shouldn't
> be lazy consensus,
> no matter if done in trunk or branch, i.e. result of one individual
> submitting (valid) code.
> It needs some more comunity involvment.
No one has said that at all, afaik. So I agree with your
strawman argument :)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Review model take 2
Posted by Costin Manolache <co...@gmail.com>.
On 9/21/07, Jim Jagielski <ji...@jagunet.com> wrote:
>
>
> On Sep 21, 2007, at 1:23 PM, Costin Manolache wrote:
>
> There are 2 ways for code in trunk to get released:
>
> 1. trunk, the whole kit and kaboodle becomes a release
> branch. For this to happen, RTC comes in and the
> PMC and dev community agree that trunk should serve
> as the basis for TC X.Y.
Ok, but what is the decision process about what goes into the
trunk, in case changes lack consensus ?
Let's assume CTR ( lazy consensus - i.e. assume everyone agrees ) - what if
it
turns that the consensus is lacking, not on the technical validity of the
change
but on weather a particular change is the right direction. Should tomcat
bundle the
CGI / SSI support - or have a smaller set of feature in the base, like jetty
? NIO or apr ?
Keep backward compat or fix major problems - and what's the middle line ?
Current process seems to be 'everyone throws whatever in the trunk - as long
as nobody
can find a valid technicality for a veto, at the end the community takes the
whole things
and agrees/disagrees'. I.e. what we had so far, leading to lots of
frustration on both
sides. And if 2 people have different opinion on an API in the trunck -
first to make the change
that can't be vetoed, or gives up in the flame war - wins.
API and big, long term changes and the direction of the project shouldn't
be lazy consensus,
no matter if done in trunk or branch, i.e. result of one individual
submitting (valid) code.
It needs some more comunity involvment.
Costin
Re: Review model take 2
Posted by Jim Jagielski <ji...@jaguNET.com>.
On Sep 21, 2007, at 1:23 PM, Costin Manolache wrote:
>
> I'm a bit confused - what happens with the trunk then ? Usually the
> trunk will become the new release - or the code from the trunk will
> somehow
> get released.
>
There are 2 ways for code in trunk to get released:
1. trunk, the whole kit and kaboodle becomes a release
branch. For this to happen, RTC comes in and the
PMC and dev community agree that trunk should serve
as the basis for TC X.Y.
2. Parts of trunk end up in releases. For this
to happen a patch is proposed for backport to
a release branch under RTC rules. Normally, this is
noted and voted on in a STATUS file.
trunk continues to be operated under CTR, but all code *from*
trunk that goes into a release branch is via RTC.
> But forget the release/trunk details - the question is how to
> determine the
> goals or direction - things like should use switch coyote to nio,
> should we
> change the API in one way or another, how much backward
> compatibility to
> preserve, what to deprecate and what to bundle by default. Doesn't
> matter
> where
> it happens - the reason we have this conversation is because this
> kind of
> decision was made by one or 2 people fighting each other and without
> enough consensus - instead of the broader community.
>
> Both Remy and Filip ( and quite a few other people actually ) are
> quick to
> express their disapproval for something or their goals - and maybe
> sometimes
> too blunt
> and personal.
>
> The proposed processes ( with their evident flaws ) are intended
> to make it clear that neither of us 'decides' ( by veto or by
> sumitting
> something ) -
> either we have a consensus ( everyone agrees ), or at least the
> typical 3
> +1 and
> majority.
All good points. It just seems to me that the voting should be
on code that, as you said, affects people. When the code enters
a release branch, then approval is needed. The fact that it's
been in trunk and has worked well and that others within
the PMC and dev community have played and worked with it
will count for something, but it is still a RTC rule. Having
trunk means we get consensus twice: the 1st under CTR (a lazy
consensus to be sure) and then when moved to release under
RTC.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Review model take 2
Posted by Costin Manolache <co...@gmail.com>.
On 9/21/07, Jim Jagielski <ji...@jagunet.com> wrote:
>
>
> On Sep 21, 2007, at 11:12 AM, Costin Manolache wrote:
>
> > I agree with the previous mail that for a while people will be
> > careful to
> > discuss and review - so probably we don't really need to do anything,
> > this long thread may have raised enough awareness.
> >
> > Regarding release numbers - I also agree with you on such a scheme.
> >
> > My only concern with your last 2 emails: it doesn't address the root
> > problem,
> > what kind of decision-making should be done in the 6.3/6.5/trunk/
> > dev branch,
> > on API changes and core features ( i.e. things that will indirectly
> > affect
> > other people ) ?
> >
> > It is clear that the previous model doesn't work - any developer
> > submitting
> > code ( usually valid ),
> > and then fighting over why a veto is invalid. We do need a way to
> > have core
> > changes
> > reviewed by more people and be sure we have a fight-free, polite
> > mode of
> > expressing 'I don't
> > think we should do this in the core, please try a different
> > approach - maybe
> > a plugin, or
> > a new connector, etc' - without arguing about the actual change
> > itself, just
> > about the direction
> > we want for the project. And this should involve more than 2 opinions.
> >
> > I still think the proposal to do CTR, assuming consensus exists,
> > but on any
> > sign of disagreement on
> > a change affecting the 'core' - fall back to RTC ( or request a
> > simple vote,
> > 3+1 and more + than - on
> > the _goals_, instead of the implementation ). This should also be done
> > before including new big features
> > to be bundled in the next release.
> >
>
> But anything that *reaches* a release branch is ALWAYS RTC. So,
> by design and definition, anything that affects other people,
> does so because it is part of a release branch and therefore,
> since it is part of the release branch, got in there via RTC.
I'm a bit confused - what happens with the trunk then ? Usually the
trunk will become the new release - or the code from the trunk will somehow
get released.
But forget the release/trunk details - the question is how to determine the
goals or direction - things like should use switch coyote to nio, should we
change the API in one way or another, how much backward compatibility to
preserve, what to deprecate and what to bundle by default. Doesn't matter
where
it happens - the reason we have this conversation is because this kind of
decision was made by one or 2 people fighting each other and without
enough consensus - instead of the broader community.
Both Remy and Filip ( and quite a few other people actually ) are quick to
express their disapproval for something or their goals - and maybe sometimes
too blunt
and personal.
The proposed processes ( with their evident flaws ) are intended
to make it clear that neither of us 'decides' ( by veto or by sumitting
something ) -
either we have a consensus ( everyone agrees ), or at least the typical 3
+1 and
majority.
Costin
Re: Review model take 2
Posted by Jim Jagielski <ji...@jaguNET.com>.
On Sep 21, 2007, at 11:12 AM, Costin Manolache wrote:
> I agree with the previous mail that for a while people will be
> careful to
> discuss and review - so probably we don't really need to do anything,
> this long thread may have raised enough awareness.
>
> Regarding release numbers - I also agree with you on such a scheme.
>
> My only concern with your last 2 emails: it doesn't address the root
> problem,
> what kind of decision-making should be done in the 6.3/6.5/trunk/
> dev branch,
> on API changes and core features ( i.e. things that will indirectly
> affect
> other people ) ?
>
> It is clear that the previous model doesn't work - any developer
> submitting
> code ( usually valid ),
> and then fighting over why a veto is invalid. We do need a way to
> have core
> changes
> reviewed by more people and be sure we have a fight-free, polite
> mode of
> expressing 'I don't
> think we should do this in the core, please try a different
> approach - maybe
> a plugin, or
> a new connector, etc' - without arguing about the actual change
> itself, just
> about the direction
> we want for the project. And this should involve more than 2 opinions.
>
> I still think the proposal to do CTR, assuming consensus exists,
> but on any
> sign of disagreement on
> a change affecting the 'core' - fall back to RTC ( or request a
> simple vote,
> 3+1 and more + than - on
> the _goals_, instead of the implementation ). This should also be done
> before including new big features
> to be bundled in the next release.
>
But anything that *reaches* a release branch is ALWAYS RTC. So,
by design and definition, anything that affects other people,
does so because it is part of a release branch and therefore,
since it is part of the release branch, got in there via RTC.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Review model take 2
Posted by Costin Manolache <co...@gmail.com>.
I agree with the previous mail that for a while people will be careful to
discuss and review - so probably we don't really need to do anything,
this long thread may have raised enough awareness.
Regarding release numbers - I also agree with you on such a scheme.
My only concern with your last 2 emails: it doesn't address the root
problem,
what kind of decision-making should be done in the 6.3/6.5/trunk/dev branch,
on API changes and core features ( i.e. things that will indirectly affect
other people ) ?
It is clear that the previous model doesn't work - any developer submitting
code ( usually valid ),
and then fighting over why a veto is invalid. We do need a way to have core
changes
reviewed by more people and be sure we have a fight-free, polite mode of
expressing 'I don't
think we should do this in the core, please try a different approach - maybe
a plugin, or
a new connector, etc' - without arguing about the actual change itself, just
about the direction
we want for the project. And this should involve more than 2 opinions.
I still think the proposal to do CTR, assuming consensus exists, but on any
sign of disagreement on
a change affecting the 'core' - fall back to RTC ( or request a simple vote,
3+1 and more + than - on
the _goals_, instead of the implementation ). This should also be done
before including new big features
to be bundled in the next release.
Costin
On 9/21/07, Jim Jagielski <ji...@jagunet.com> wrote:
>
> Posted on another list, but adding it here with some
> refinements:
>
> If I had my druthers I'd say we have all release branches
> created and set as RTC. We then follow a release
> number similar to httpd and others where even number
> minors are release, and odd numbers are development.
> We then have a real trunk, using whatever bits and pieces
> of what we currently have and call that TC 6.3 (thus
> allowing for a 6.2 being created from it if so deemed).
> This also allows for patches/code/features to be
> applied in 6.3 and proposed for backport to 6.0
> (again, ala httpd and others). 6.3/6.2 also serves as
> the community testbed for not only new features but
> a plugin/module architecture.
>
> This can be refined by bumping up to 6.5/6.4 for the
> more future reaching stuff and allowing for a 6.3/6.2 for
> some feature of the old trunk that external projects
> were using/depending on...
>
> Trunk, of course, would be CTR. Backports and release
> branches would be RTC. Development branches (the odd numbered
> ones) would be CTR.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
>
Re: Review model take 2
Posted by Jim Jagielski <ji...@jaguNET.com>.
Posted on another list, but adding it here with some
refinements:
If I had my druthers I'd say we have all release branches
created and set as RTC. We then follow a release
number similar to httpd and others where even number
minors are release, and odd numbers are development.
We then have a real trunk, using whatever bits and pieces
of what we currently have and call that TC 6.3 (thus
allowing for a 6.2 being created from it if so deemed).
This also allows for patches/code/features to be
applied in 6.3 and proposed for backport to 6.0
(again, ala httpd and others). 6.3/6.2 also serves as
the community testbed for not only new features but
a plugin/module architecture.
This can be refined by bumping up to 6.5/6.4 for the
more future reaching stuff and allowing for a 6.3/6.2 for
some feature of the old trunk that external projects
were using/depending on...
Trunk, of course, would be CTR. Backports and release
branches would be RTC. Development branches (the odd numbered
ones) would be CTR.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Review model take 2
Posted by Jim Jagielski <ji...@jaguNET.com>.
On Sep 21, 2007, at 4:45 AM, Henri Gomez wrote:
> +1
>
> RTC is a good idea for release and fixes.
>
> Let's make use of RTC for release and CTR for more experimental code.
>
I agree. I think that no on can disagree that, more than
anything else, right now, more people will be focused on
patches, watching over people's shoulders and *communicating*
issues/concerns/problems with patches and development than
most likely ever before.
So why not *use* that... when the above is the case, then
CTR and RTC and "normal" ASF communal development works...
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Review model take 2
Posted by Henri Gomez <he...@gmail.com>.
+1
RTC is a good idea for release and fixes.
Let's make use of RTC for release and CTR for more experimental code.
2007/9/21, jean-frederic clere <jf...@gmail.com>:
> Filip Hanik - Dev Lists wrote:
> > It could be a simple as (as opposed to trying to reinvent the apache way)
> >
> > 1. Through out a vote for the 6.0.x/5.5.x/5.0.x/4.1.x branches RTC or CTR
>
> Every one should why Sun had forked from Tomcat... I am sure a RTC on
> stable branches would have prevent it.
>
> None needs a toy for production.
> Why do you think Apache httpd is still the best open source WEB server
> (see http://www.infoworld.com/slideshow/2007/09/114-best_of_open_so-5.html)?
> - Because stable branches are really stable why are they so stable
> because they use RTC.
>
> > 2. We'll all pay more attention to discussing a change prior to SVN
> > commit whether it is RTC or CTR
> > But we don't need a "new process" for this
>
> That is not a new process what we need is to define what to do if the
> consensus doesn't come out when the review ended in "please stop we need
> to discuss that commit/feature/fix".
>
>
> > 3. Bring back trunk as CTR, again, following the advice in step 2 (yes,
> > me included)
>
> yes we need a place for common innovation.
>
> >
> > And have it all over with. The reason I'm opposing here is that the
> > tomcat community is trying to (re)invent a new development process.
> > Trust me, if there was a better way, someone else would have probably
> > thought of it, it's not like we are the originators and demi gods of
> > programming.
> > The reason we are at the ASF, is to piggy back on the ASF ways, as
> > simple as that.
>
> Again something worked wrong you can say it is your fault (and tell it
> to everyone (including Remy)) but nothing prevents that happening again.
> Should we define a process to prevent that? For me yes.
>
> Cheers
>
> Jean-frederic
>
> >
> > Filip
> >
> >
> >
> > jkew wrote:
> >> Folks,
> >>
> >> I'm somewhat on the outside looking here, so I'm probably going to be
> >> a little naive:
> >>
> >> 1. It's really time to come to a conclusion on this, before people get
> >> too exhausted and give up.
> >> 2. Ideally everyone should compromise a little on a solution, but this
> >> doesn't always happen.
> >> 3. People really hate making decisions that are going to be set in
> >> stone, especially when they are emotionally involved.
> >>
> >> What about a trial period of three(or 'n') months for a review model?
> >> People who hate the review model may be more willing to compromise a
> >> bit more for a 'test' phase. The review model does not have to be set
> >> in stone, but we do need something in place until people can calm down.
> >>
> >> 1. Those who compromise more than others should be willing to give the
> >> new system an n month trial period to allow a new process a chance to
> >> settle w/o constant criticism.
> >> 2. Those who compromised less should be willing to change the system
> >> after the n month trial period.
> >>
> >> Whether it is Remy's plan or another, it is really important to codify
> >> some process at this point. I would rather not waste any more bits on
> >> this. I hate the idea of proposing anything at all in the middle of
> >> this discussion, but we have got to get past this.
> >>
> >> -John
> >>
> >> Remy Maucherat wrote:
> >>> Hi,
> >>>
> >>> Another more precise draft.
> >>>
> >>> Patches which would go to review would be:
> >>> - API changing patches (any protected or above signature change) on
> >>> APIs which are accessible to the user either from confirguration or
> >>> programmatically
> >>> - any other commit for which a committer asks for the RTC procedure
> >>> should be rollbacked if it hinders concurrent work or is to be
> >>> included in a release tag, and go through the RTC procedure
> >>>
> >>> The RTC procedure would include a STATUS file in the Tomcat svn
> >>> listing all pending "up to review" changes. A successful vote with a
> >>> +3 margin is required. A patch can remain under review for as long as
> >>> the committer wishes, and it should be allowed to freely "advertise"
> >>> and discuss the vote.
> >>>
> >>> The idea would be to force a consensus for commits which could have
> >>> significant implications, and help stage technical discussions
> >>> (rather than discussions about the validity of the disagreement). It
> >>> would introduce a small delay for committing certain patches and a
> >>> minor slowdown for development pace in theory, but in practice I've
> >>> noticed conflicts waste a lot more time.
> >>>
> >>> This would also mean it is possible to make a change that a number of
> >>> committers oppose (possibly, would veto) if enough committers are in
> >>> favor of it.
> >>>
> >>> Rémy
> >>>
> >>>
> >>> ---------------------------------------------------------------------
> >>> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> >>> For additional commands, e-mail: dev-help@tomcat.apache.org
> >>>
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> >> For additional commands, e-mail: dev-help@tomcat.apache.org
> >>
> >>
> >>
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> > For additional commands, e-mail: dev-help@tomcat.apache.org
> >
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Review model take 2
Posted by Jim Jagielski <ji...@jaguNET.com>.
On Sep 21, 2007, at 4:07 AM, jean-frederic clere wrote:
> Filip Hanik - Dev Lists wrote:
>> It could be a simple as (as opposed to trying to reinvent the
>> apache way)
>>
>> 1. Through out a vote for the 6.0.x/5.5.x/5.0.x/4.1.x branches RTC
>> or CTR
>
> Every one should why Sun had forked from Tomcat... I am sure a RTC on
> stable branches would have prevent it.
>
It's no secret that another reason was the Sun could no
longer tolerate some of the personalities within TC.
I stress again that for years and years, TC has not been
seen as a happy, welcoming place to be. It's just that
things have reached a head at this point.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Review model take 2
Posted by jean-frederic clere <jf...@gmail.com>.
Filip Hanik - Dev Lists wrote:
> It could be a simple as (as opposed to trying to reinvent the apache way)
>
> 1. Through out a vote for the 6.0.x/5.5.x/5.0.x/4.1.x branches RTC or CTR
Every one should why Sun had forked from Tomcat... I am sure a RTC on
stable branches would have prevent it.
None needs a toy for production.
Why do you think Apache httpd is still the best open source WEB server
(see http://www.infoworld.com/slideshow/2007/09/114-best_of_open_so-5.html)?
- Because stable branches are really stable why are they so stable
because they use RTC.
> 2. We'll all pay more attention to discussing a change prior to SVN
> commit whether it is RTC or CTR
> But we don't need a "new process" for this
That is not a new process what we need is to define what to do if the
consensus doesn't come out when the review ended in "please stop we need
to discuss that commit/feature/fix".
> 3. Bring back trunk as CTR, again, following the advice in step 2 (yes,
> me included)
yes we need a place for common innovation.
>
> And have it all over with. The reason I'm opposing here is that the
> tomcat community is trying to (re)invent a new development process.
> Trust me, if there was a better way, someone else would have probably
> thought of it, it's not like we are the originators and demi gods of
> programming.
> The reason we are at the ASF, is to piggy back on the ASF ways, as
> simple as that.
Again something worked wrong you can say it is your fault (and tell it
to everyone (including Remy)) but nothing prevents that happening again.
Should we define a process to prevent that? For me yes.
Cheers
Jean-frederic
>
> Filip
>
>
>
> jkew wrote:
>> Folks,
>>
>> I'm somewhat on the outside looking here, so I'm probably going to be
>> a little naive:
>>
>> 1. It's really time to come to a conclusion on this, before people get
>> too exhausted and give up.
>> 2. Ideally everyone should compromise a little on a solution, but this
>> doesn't always happen.
>> 3. People really hate making decisions that are going to be set in
>> stone, especially when they are emotionally involved.
>>
>> What about a trial period of three(or 'n') months for a review model?
>> People who hate the review model may be more willing to compromise a
>> bit more for a 'test' phase. The review model does not have to be set
>> in stone, but we do need something in place until people can calm down.
>>
>> 1. Those who compromise more than others should be willing to give the
>> new system an n month trial period to allow a new process a chance to
>> settle w/o constant criticism.
>> 2. Those who compromised less should be willing to change the system
>> after the n month trial period.
>>
>> Whether it is Remy's plan or another, it is really important to codify
>> some process at this point. I would rather not waste any more bits on
>> this. I hate the idea of proposing anything at all in the middle of
>> this discussion, but we have got to get past this.
>>
>> -John
>>
>> Remy Maucherat wrote:
>>> Hi,
>>>
>>> Another more precise draft.
>>>
>>> Patches which would go to review would be:
>>> - API changing patches (any protected or above signature change) on
>>> APIs which are accessible to the user either from confirguration or
>>> programmatically
>>> - any other commit for which a committer asks for the RTC procedure
>>> should be rollbacked if it hinders concurrent work or is to be
>>> included in a release tag, and go through the RTC procedure
>>>
>>> The RTC procedure would include a STATUS file in the Tomcat svn
>>> listing all pending "up to review" changes. A successful vote with a
>>> +3 margin is required. A patch can remain under review for as long as
>>> the committer wishes, and it should be allowed to freely "advertise"
>>> and discuss the vote.
>>>
>>> The idea would be to force a consensus for commits which could have
>>> significant implications, and help stage technical discussions
>>> (rather than discussions about the validity of the disagreement). It
>>> would introduce a small delay for committing certain patches and a
>>> minor slowdown for development pace in theory, but in practice I've
>>> noticed conflicts waste a lot more time.
>>>
>>> This would also mean it is possible to make a change that a number of
>>> committers oppose (possibly, would veto) if enough committers are in
>>> favor of it.
>>>
>>> Rémy
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
>>> For additional commands, e-mail: dev-help@tomcat.apache.org
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: dev-help@tomcat.apache.org
>>
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Review model take 2
Posted by Filip Hanik - Dev Lists <de...@hanik.com>.
It could be a simple as (as opposed to trying to reinvent the apache way)
1. Through out a vote for the 6.0.x/5.5.x/5.0.x/4.1.x branches RTC or CTR
2. We'll all pay more attention to discussing a change prior to SVN
commit whether it is RTC or CTR
But we don't need a "new process" for this
3. Bring back trunk as CTR, again, following the advice in step 2 (yes,
me included)
And have it all over with. The reason I'm opposing here is that the
tomcat community is trying to (re)invent a new development process.
Trust me, if there was a better way, someone else would have probably
thought of it, it's not like we are the originators and demi gods of
programming.
The reason we are at the ASF, is to piggy back on the ASF ways, as
simple as that.
Filip
jkew wrote:
> Folks,
>
> I'm somewhat on the outside looking here, so I'm probably going to be
> a little naive:
>
> 1. It's really time to come to a conclusion on this, before people get
> too exhausted and give up.
> 2. Ideally everyone should compromise a little on a solution, but this
> doesn't always happen.
> 3. People really hate making decisions that are going to be set in
> stone, especially when they are emotionally involved.
>
> What about a trial period of three(or 'n') months for a review model?
> People who hate the review model may be more willing to compromise a
> bit more for a 'test' phase. The review model does not have to be set
> in stone, but we do need something in place until people can calm down.
>
> 1. Those who compromise more than others should be willing to give the
> new system an n month trial period to allow a new process a chance to
> settle w/o constant criticism.
> 2. Those who compromised less should be willing to change the system
> after the n month trial period.
>
> Whether it is Remy's plan or another, it is really important to codify
> some process at this point. I would rather not waste any more bits on
> this. I hate the idea of proposing anything at all in the middle of
> this discussion, but we have got to get past this.
>
> -John
>
> Remy Maucherat wrote:
>> Hi,
>>
>> Another more precise draft.
>>
>> Patches which would go to review would be:
>> - API changing patches (any protected or above signature change) on
>> APIs which are accessible to the user either from confirguration or
>> programmatically
>> - any other commit for which a committer asks for the RTC procedure
>> should be rollbacked if it hinders concurrent work or is to be
>> included in a release tag, and go through the RTC procedure
>>
>> The RTC procedure would include a STATUS file in the Tomcat svn
>> listing all pending "up to review" changes. A successful vote with a
>> +3 margin is required. A patch can remain under review for as long as
>> the committer wishes, and it should be allowed to freely "advertise"
>> and discuss the vote.
>>
>> The idea would be to force a consensus for commits which could have
>> significant implications, and help stage technical discussions
>> (rather than discussions about the validity of the disagreement). It
>> would introduce a small delay for committing certain patches and a
>> minor slowdown for development pace in theory, but in practice I've
>> noticed conflicts waste a lot more time.
>>
>> This would also mean it is possible to make a change that a number of
>> committers oppose (possibly, would veto) if enough committers are in
>> favor of it.
>>
>> Rémy
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: dev-help@tomcat.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Review model take 2
Posted by jkew <jo...@sourcelabs.com>.
Folks,
I'm somewhat on the outside looking here, so I'm probably going to be a
little naive:
1. It's really time to come to a conclusion on this, before people get
too exhausted and give up.
2. Ideally everyone should compromise a little on a solution, but this
doesn't always happen.
3. People really hate making decisions that are going to be set in
stone, especially when they are emotionally involved.
What about a trial period of three(or 'n') months for a review model?
People who hate the review model may be more willing to compromise a bit
more for a 'test' phase. The review model does not have to be set in
stone, but we do need something in place until people can calm down.
1. Those who compromise more than others should be willing to give the
new system an n month trial period to allow a new process a chance to
settle w/o constant criticism.
2. Those who compromised less should be willing to change the system
after the n month trial period.
Whether it is Remy's plan or another, it is really important to codify
some process at this point. I would rather not waste any more bits on
this. I hate the idea of proposing anything at all in the middle of this
discussion, but we have got to get past this.
-John
Remy Maucherat wrote:
> Hi,
>
> Another more precise draft.
>
> Patches which would go to review would be:
> - API changing patches (any protected or above signature change) on
> APIs which are accessible to the user either from confirguration or
> programmatically
> - any other commit for which a committer asks for the RTC procedure
> should be rollbacked if it hinders concurrent work or is to be
> included in a release tag, and go through the RTC procedure
>
> The RTC procedure would include a STATUS file in the Tomcat svn
> listing all pending "up to review" changes. A successful vote with a
> +3 margin is required. A patch can remain under review for as long as
> the committer wishes, and it should be allowed to freely "advertise"
> and discuss the vote.
>
> The idea would be to force a consensus for commits which could have
> significant implications, and help stage technical discussions (rather
> than discussions about the validity of the disagreement). It would
> introduce a small delay for committing certain patches and a minor
> slowdown for development pace in theory, but in practice I've noticed
> conflicts waste a lot more time.
>
> This would also mean it is possible to make a change that a number of
> committers oppose (possibly, would veto) if enough committers are in
> favor of it.
>
> Rémy
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Review model take 2
Posted by Mladen Turk <mt...@apache.org>.
+1 as well.
Seems we have come to some sort of conclusion.
(At least the proposal holds the majority of votes)
I'll left this tread for a day or two and then create
an official proposal draft we can vote on.
If thats accepted, I'll create needed documents like
STATUS, ROADMAP containing that draft as header.
I can also create a xml that can be added to the t.a.org
(updating http://tomcat.apache.org/getinvolved.html perhaps?)
Regards,
Mladen
Remy Maucherat wrote:
> Hi,
>
> Another more precise draft.
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Review model take 2
Posted by jean-frederic clere <jf...@gmail.com>.
+1
Cheers
Jean-Frederic
Remy Maucherat wrote:
> Hi,
>
> Another more precise draft.
>
> Patches which would go to review would be:
> - API changing patches (any protected or above signature change) on APIs
> which are accessible to the user either from confirguration or
> programmatically
> - any other commit for which a committer asks for the RTC procedure
> should be rollbacked if it hinders concurrent work or is to be included
> in a release tag, and go through the RTC procedure
>
> The RTC procedure would include a STATUS file in the Tomcat svn listing
> all pending "up to review" changes. A successful vote with a +3 margin
> is required. A patch can remain under review for as long as the
> committer wishes, and it should be allowed to freely "advertise" and
> discuss the vote.
>
> The idea would be to force a consensus for commits which could have
> significant implications, and help stage technical discussions (rather
> than discussions about the validity of the disagreement). It would
> introduce a small delay for committing certain patches and a minor
> slowdown for development pace in theory, but in practice I've noticed
> conflicts waste a lot more time.
>
> This would also mean it is possible to make a change that a number of
> committers oppose (possibly, would veto) if enough committers are in
> favor of it.
>
> Rémy
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Review model take 2
Posted by jean-frederic clere <jf...@gmail.com>.
Henri Gomez wrote:
> So what about RTC for core and CTR for extensions in incubator land ?
Well see the result of the "[VOTE] Make released versions RTC".
We need 2 things innovation (on a common trunk) and stability on
released branches. That why I made the proposal "[VOTE] Make released
versions RTC".
CTR didn't seem to work on the "old" trunk and we have to prevent this
happening again, therefore comes the idea of a "RTC on demand".
Cheers
Jean-Frederic
>
> 2007/9/21, Costin Manolache <co...@gmail.com>:
>> I have a strong feeling this is turning again into a debate over words,
>> arcane details
>> and abstract concepts ( 'what is a trunk' and how to increase innovation )
>>
>> The real issue is quite simple, and not having a trunk or all the new
>> process seems
>> more like an attempt to solve it:
>>
>> We want tomcat evolution to be done by consensus or at least majority, not
>> by one
>> individual ( be it Remy or Filip or anyone else ) making decisions and
>> changes to the core API without
>> consultation and agreement from others ( and yes, most vetoes are probably
>> invalid and
>> bad - the changes are technically ok, and the veto is a blunt tool to
>> express lack of consensus
>> and frustration ).
>>
>> The whole veto / remove trunk / personal hurt feelings / CTR / RTC / process
>> debate
>> is just a way to avoid this from happening.
>>
>> Yes, we want innovation and change and contributions and all that - but that
>> doesn't mean
>> that anyone who can make a technically valid change ( i.e. where a veto
>> would be invalid )
>> should make it - if it affects other people and it lacks consensus.
>>
>> That doesn't mean you can't add features ( to 6.0 or trunk or however you
>> want to call it ), or you
>> can't make big changes, or someone can block 'progress' or impose his own
>> vision of progress.
>> All those proposals evolve around how to involve more people in decision
>> making and be as close
>> to consensus as possible.
>>
>> I personally consider tomcat way overbloated - so I think I'm on the same
>> side with Remy on voting against
>> adding any new feature that could be done as a plugin, and I would be happy
>> to see 'innovations'
>> in tomcat removed from std and moved to separate plugins, until we're at the
>> same size with jetty
>> or other containers in the base distro. But I do understand Filip's
>> frustration and the desire to try now
>> things - and this should happen, not in sandbox but in 6.0 tree, except not
>> in the core and with
>> controlled API changes.
>>
>>
>> Costin
>>
>> On 9/20/07, William A. Rowe, Jr. <wr...@rowe-clan.net> wrote:
>>> Will f/w board since this follows from the 'no more trunk' comment which
>>> some officers questioned. Please don't cc per-say, but feel free to f/w
>>> a relevant response to board@a.o (it's bad form to crosspost a message
>>> with both public-and-private destinations).
>>>
>>> Bill Barker wrote:
>>>> "William A. Rowe, Jr." <wr...@rowe-clan.net> wrote in message
>>>>> All that said, the topic of "no more trunk" came up at the board
>>> meeting
>>>>> today. I gave a very brief background and suggested that some of the
>>>>> renewed interest by folks who had been silent throughout the Filip-Remy
>>>>> trunk war is a hopeful sign; with renewed interest the project is very
>>>>> likely to be able to manage itself successfully through these personal
>>>>> and stylistic disagreements; the board is satisfied to see the project
>>>>> try to work out these issues themselves as long as development once
>>> again
>>>>> is encouraged.
>>>> TC 4.1.x and TC 5.5.x represented major changes to the core API, and
>>>> resulted in much more stable Tomcat code. There is no such issue for TC
>>>> 6.0.x (just a disagreement on the comet API, which we have already dealt
>>>> with, and decided to let software-darwinism take it's course). Thus,
>>> there
>>>> is really no reason for a "trunk" at this time, at least until the
>>> Servlet
>>>> 3.0 spec comes out. If somebody wanted to make a [PROPOSAL] for major
>>>> changes to the core TC 6.0.x API, then I can see setting up a "trunk"
>>> again.
>>>> But there is no such animal lurking at this time.
>>> No doubt, these were significant departures from their previous code.
>>>
>>> But, are you suggesting that there is no need for trunk until there is an
>>> idea you happen to champion? Present you with an idea that you like and
>>> half the committee might decide to permit new development again?
>>>
>>> This is certainly turning the idea of "show me the code" on it's head.
>>>
>>> To give an example oft cited on this list, httpd maintains a trunk. It
>>> might be released some day as-is, it might never be released. But it's
>>> a staging ground to prove up an idea before injecting that idea into the
>>> shipping stable version. It appears there is no such wilderness at
>>> Tomcat.
>>>
>>> Sandboxes don't cut it. It's very clear sandboxes are one-man-shows at
>>> Tomcat. As such, they go against the concept of collaborative development
>>> and don't belong at the foundation. If I misunderstand, and sandboxes are
>>> shared spaces for proving concept-not-the-programmer, and everyone is
>>> welcome at each sandbox to improve the proof of concept themselves, then
>>> my objection is unfounded.
>>>
>>> It seems the list wants very tight control on the stable 6.0 branch, so
>>> your observation that trunk is irrelevant hasn't jived since I first read
>>> this post (and I considered it's implications for a good 12 hrs).
>>>
>>> It also brings up a real question of why was it so important to 'kill
>>> trunk' if trunk, admittedly, is not relevant?
>>>
>>>>> But without reestablishing a method for the committers to innovate, or
>>>>> with continued/renewed territorial behaviors, this issue will likely
>>>>> be noticed again by the board a few months from now as an issue in need
>>>>> of a solution.
>>>> I maintain that there is currently a very small barrier to "innovating"
>>> on
>>>> Tomcat. We had one innovation that was shown to have a big whopping
>>>> security hole in it, so it was withdrawn until a better patch can be
>>> made
>>>> (i.e. the system worked). There were people (myself included) that
>>> would
>>>> have preferred a modular patch (e.g. with httpd, I can configure it so
>>> that
>>>> mod_alias isn't included with a few small edits, but the patch in
>>> question
>>>> didn't allow for that, which was the complaints).
>>> You are talking about one patch. Has Tomcat become so pathetic that
>>> there's
>>> only one example of innovation in the past /x/ months to hold up as the
>>> one
>>> true example?
>>>
>>> Let's hope the rule systems that Tomcat debates and settles on reflect the
>>> diversity of contributions, as opposed to a small handful of exceptions.
>>> The fact that the rule systems themselves are being debated points me to
>>> really wonder if there is any code debate here at all, or nothing more
>>> than
>>> a clash of personalities which "changing the rules" is the simplest
>>> solution
>>> to getting one's way?
>>>
>>> In any case, the list continues to ponder what the meaning of the
>>> branches,
>>> sandboxes etc all are, and I'll step out of this conversation (baring any
>>> truly insane proposals) while the TC core community comes to terms with
>>> how
>>> Tomcat can still prosper, and lose the perception of being a fiefdom of
>>> the
>>> chosen few.
>>>
>>> Bill
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
>>> For additional commands, e-mail: dev-help@tomcat.apache.org
>>>
>>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Review model take 2
Posted by Henri Gomez <he...@gmail.com>.
So what about RTC for core and CTR for extensions in incubator land ?
2007/9/21, Costin Manolache <co...@gmail.com>:
> I have a strong feeling this is turning again into a debate over words,
> arcane details
> and abstract concepts ( 'what is a trunk' and how to increase innovation )
>
> The real issue is quite simple, and not having a trunk or all the new
> process seems
> more like an attempt to solve it:
>
> We want tomcat evolution to be done by consensus or at least majority, not
> by one
> individual ( be it Remy or Filip or anyone else ) making decisions and
> changes to the core API without
> consultation and agreement from others ( and yes, most vetoes are probably
> invalid and
> bad - the changes are technically ok, and the veto is a blunt tool to
> express lack of consensus
> and frustration ).
>
> The whole veto / remove trunk / personal hurt feelings / CTR / RTC / process
> debate
> is just a way to avoid this from happening.
>
> Yes, we want innovation and change and contributions and all that - but that
> doesn't mean
> that anyone who can make a technically valid change ( i.e. where a veto
> would be invalid )
> should make it - if it affects other people and it lacks consensus.
>
> That doesn't mean you can't add features ( to 6.0 or trunk or however you
> want to call it ), or you
> can't make big changes, or someone can block 'progress' or impose his own
> vision of progress.
> All those proposals evolve around how to involve more people in decision
> making and be as close
> to consensus as possible.
>
> I personally consider tomcat way overbloated - so I think I'm on the same
> side with Remy on voting against
> adding any new feature that could be done as a plugin, and I would be happy
> to see 'innovations'
> in tomcat removed from std and moved to separate plugins, until we're at the
> same size with jetty
> or other containers in the base distro. But I do understand Filip's
> frustration and the desire to try now
> things - and this should happen, not in sandbox but in 6.0 tree, except not
> in the core and with
> controlled API changes.
>
>
> Costin
>
> On 9/20/07, William A. Rowe, Jr. <wr...@rowe-clan.net> wrote:
> >
> > Will f/w board since this follows from the 'no more trunk' comment which
> > some officers questioned. Please don't cc per-say, but feel free to f/w
> > a relevant response to board@a.o (it's bad form to crosspost a message
> > with both public-and-private destinations).
> >
> > Bill Barker wrote:
> > > "William A. Rowe, Jr." <wr...@rowe-clan.net> wrote in message
> > >>
> > >> All that said, the topic of "no more trunk" came up at the board
> > meeting
> > >> today. I gave a very brief background and suggested that some of the
> > >> renewed interest by folks who had been silent throughout the Filip-Remy
> > >> trunk war is a hopeful sign; with renewed interest the project is very
> > >> likely to be able to manage itself successfully through these personal
> > >> and stylistic disagreements; the board is satisfied to see the project
> > >> try to work out these issues themselves as long as development once
> > again
> > >> is encouraged.
> > >
> > > TC 4.1.x and TC 5.5.x represented major changes to the core API, and
> > > resulted in much more stable Tomcat code. There is no such issue for TC
> > > 6.0.x (just a disagreement on the comet API, which we have already dealt
> > > with, and decided to let software-darwinism take it's course). Thus,
> > there
> > > is really no reason for a "trunk" at this time, at least until the
> > Servlet
> > > 3.0 spec comes out. If somebody wanted to make a [PROPOSAL] for major
> > > changes to the core TC 6.0.x API, then I can see setting up a "trunk"
> > again.
> > > But there is no such animal lurking at this time.
> >
> > No doubt, these were significant departures from their previous code.
> >
> > But, are you suggesting that there is no need for trunk until there is an
> > idea you happen to champion? Present you with an idea that you like and
> > half the committee might decide to permit new development again?
> >
> > This is certainly turning the idea of "show me the code" on it's head.
> >
> > To give an example oft cited on this list, httpd maintains a trunk. It
> > might be released some day as-is, it might never be released. But it's
> > a staging ground to prove up an idea before injecting that idea into the
> > shipping stable version. It appears there is no such wilderness at
> > Tomcat.
> >
> > Sandboxes don't cut it. It's very clear sandboxes are one-man-shows at
> > Tomcat. As such, they go against the concept of collaborative development
> > and don't belong at the foundation. If I misunderstand, and sandboxes are
> > shared spaces for proving concept-not-the-programmer, and everyone is
> > welcome at each sandbox to improve the proof of concept themselves, then
> > my objection is unfounded.
> >
> > It seems the list wants very tight control on the stable 6.0 branch, so
> > your observation that trunk is irrelevant hasn't jived since I first read
> > this post (and I considered it's implications for a good 12 hrs).
> >
> > It also brings up a real question of why was it so important to 'kill
> > trunk' if trunk, admittedly, is not relevant?
> >
> > >> But without reestablishing a method for the committers to innovate, or
> > >> with continued/renewed territorial behaviors, this issue will likely
> > >> be noticed again by the board a few months from now as an issue in need
> > >> of a solution.
> > >
> > > I maintain that there is currently a very small barrier to "innovating"
> > on
> > > Tomcat. We had one innovation that was shown to have a big whopping
> > > security hole in it, so it was withdrawn until a better patch can be
> > made
> > > (i.e. the system worked). There were people (myself included) that
> > would
> > > have preferred a modular patch (e.g. with httpd, I can configure it so
> > that
> > > mod_alias isn't included with a few small edits, but the patch in
> > question
> > > didn't allow for that, which was the complaints).
> >
> > You are talking about one patch. Has Tomcat become so pathetic that
> > there's
> > only one example of innovation in the past /x/ months to hold up as the
> > one
> > true example?
> >
> > Let's hope the rule systems that Tomcat debates and settles on reflect the
> > diversity of contributions, as opposed to a small handful of exceptions.
> > The fact that the rule systems themselves are being debated points me to
> > really wonder if there is any code debate here at all, or nothing more
> > than
> > a clash of personalities which "changing the rules" is the simplest
> > solution
> > to getting one's way?
> >
> > In any case, the list continues to ponder what the meaning of the
> > branches,
> > sandboxes etc all are, and I'll step out of this conversation (baring any
> > truly insane proposals) while the TC core community comes to terms with
> > how
> > Tomcat can still prosper, and lose the perception of being a fiefdom of
> > the
> > chosen few.
> >
> > Bill
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> > For additional commands, e-mail: dev-help@tomcat.apache.org
> >
> >
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Review model take 2
Posted by Costin Manolache <co...@gmail.com>.
I have a strong feeling this is turning again into a debate over words,
arcane details
and abstract concepts ( 'what is a trunk' and how to increase innovation )
The real issue is quite simple, and not having a trunk or all the new
process seems
more like an attempt to solve it:
We want tomcat evolution to be done by consensus or at least majority, not
by one
individual ( be it Remy or Filip or anyone else ) making decisions and
changes to the core API without
consultation and agreement from others ( and yes, most vetoes are probably
invalid and
bad - the changes are technically ok, and the veto is a blunt tool to
express lack of consensus
and frustration ).
The whole veto / remove trunk / personal hurt feelings / CTR / RTC / process
debate
is just a way to avoid this from happening.
Yes, we want innovation and change and contributions and all that - but that
doesn't mean
that anyone who can make a technically valid change ( i.e. where a veto
would be invalid )
should make it - if it affects other people and it lacks consensus.
That doesn't mean you can't add features ( to 6.0 or trunk or however you
want to call it ), or you
can't make big changes, or someone can block 'progress' or impose his own
vision of progress.
All those proposals evolve around how to involve more people in decision
making and be as close
to consensus as possible.
I personally consider tomcat way overbloated - so I think I'm on the same
side with Remy on voting against
adding any new feature that could be done as a plugin, and I would be happy
to see 'innovations'
in tomcat removed from std and moved to separate plugins, until we're at the
same size with jetty
or other containers in the base distro. But I do understand Filip's
frustration and the desire to try now
things - and this should happen, not in sandbox but in 6.0 tree, except not
in the core and with
controlled API changes.
Costin
On 9/20/07, William A. Rowe, Jr. <wr...@rowe-clan.net> wrote:
>
> Will f/w board since this follows from the 'no more trunk' comment which
> some officers questioned. Please don't cc per-say, but feel free to f/w
> a relevant response to board@a.o (it's bad form to crosspost a message
> with both public-and-private destinations).
>
> Bill Barker wrote:
> > "William A. Rowe, Jr." <wr...@rowe-clan.net> wrote in message
> >>
> >> All that said, the topic of "no more trunk" came up at the board
> meeting
> >> today. I gave a very brief background and suggested that some of the
> >> renewed interest by folks who had been silent throughout the Filip-Remy
> >> trunk war is a hopeful sign; with renewed interest the project is very
> >> likely to be able to manage itself successfully through these personal
> >> and stylistic disagreements; the board is satisfied to see the project
> >> try to work out these issues themselves as long as development once
> again
> >> is encouraged.
> >
> > TC 4.1.x and TC 5.5.x represented major changes to the core API, and
> > resulted in much more stable Tomcat code. There is no such issue for TC
> > 6.0.x (just a disagreement on the comet API, which we have already dealt
> > with, and decided to let software-darwinism take it's course). Thus,
> there
> > is really no reason for a "trunk" at this time, at least until the
> Servlet
> > 3.0 spec comes out. If somebody wanted to make a [PROPOSAL] for major
> > changes to the core TC 6.0.x API, then I can see setting up a "trunk"
> again.
> > But there is no such animal lurking at this time.
>
> No doubt, these were significant departures from their previous code.
>
> But, are you suggesting that there is no need for trunk until there is an
> idea you happen to champion? Present you with an idea that you like and
> half the committee might decide to permit new development again?
>
> This is certainly turning the idea of "show me the code" on it's head.
>
> To give an example oft cited on this list, httpd maintains a trunk. It
> might be released some day as-is, it might never be released. But it's
> a staging ground to prove up an idea before injecting that idea into the
> shipping stable version. It appears there is no such wilderness at
> Tomcat.
>
> Sandboxes don't cut it. It's very clear sandboxes are one-man-shows at
> Tomcat. As such, they go against the concept of collaborative development
> and don't belong at the foundation. If I misunderstand, and sandboxes are
> shared spaces for proving concept-not-the-programmer, and everyone is
> welcome at each sandbox to improve the proof of concept themselves, then
> my objection is unfounded.
>
> It seems the list wants very tight control on the stable 6.0 branch, so
> your observation that trunk is irrelevant hasn't jived since I first read
> this post (and I considered it's implications for a good 12 hrs).
>
> It also brings up a real question of why was it so important to 'kill
> trunk' if trunk, admittedly, is not relevant?
>
> >> But without reestablishing a method for the committers to innovate, or
> >> with continued/renewed territorial behaviors, this issue will likely
> >> be noticed again by the board a few months from now as an issue in need
> >> of a solution.
> >
> > I maintain that there is currently a very small barrier to "innovating"
> on
> > Tomcat. We had one innovation that was shown to have a big whopping
> > security hole in it, so it was withdrawn until a better patch can be
> made
> > (i.e. the system worked). There were people (myself included) that
> would
> > have preferred a modular patch (e.g. with httpd, I can configure it so
> that
> > mod_alias isn't included with a few small edits, but the patch in
> question
> > didn't allow for that, which was the complaints).
>
> You are talking about one patch. Has Tomcat become so pathetic that
> there's
> only one example of innovation in the past /x/ months to hold up as the
> one
> true example?
>
> Let's hope the rule systems that Tomcat debates and settles on reflect the
> diversity of contributions, as opposed to a small handful of exceptions.
> The fact that the rule systems themselves are being debated points me to
> really wonder if there is any code debate here at all, or nothing more
> than
> a clash of personalities which "changing the rules" is the simplest
> solution
> to getting one's way?
>
> In any case, the list continues to ponder what the meaning of the
> branches,
> sandboxes etc all are, and I'll step out of this conversation (baring any
> truly insane proposals) while the TC core community comes to terms with
> how
> Tomcat can still prosper, and lose the perception of being a fiefdom of
> the
> chosen few.
>
> Bill
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
>
Re: Review model take 2
Posted by Remy Maucherat <re...@apache.org>.
William A. Rowe, Jr. wrote:
> It also brings up a real question of why was it so important to 'kill
> trunk' if trunk, admittedly, is not relevant?
Trunk was the sandbox of only one committer, so as far as I am concerned
it was no longer appropriate (as a trunk branch, personally I have no
problem with sandboxes or other similar experimentation places).
Rémy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Review model take 2
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
Will f/w board since this follows from the 'no more trunk' comment which
some officers questioned. Please don't cc per-say, but feel free to f/w
a relevant response to board@a.o (it's bad form to crosspost a message
with both public-and-private destinations).
Bill Barker wrote:
> "William A. Rowe, Jr." <wr...@rowe-clan.net> wrote in message
>>
>> All that said, the topic of "no more trunk" came up at the board meeting
>> today. I gave a very brief background and suggested that some of the
>> renewed interest by folks who had been silent throughout the Filip-Remy
>> trunk war is a hopeful sign; with renewed interest the project is very
>> likely to be able to manage itself successfully through these personal
>> and stylistic disagreements; the board is satisfied to see the project
>> try to work out these issues themselves as long as development once again
>> is encouraged.
>
> TC 4.1.x and TC 5.5.x represented major changes to the core API, and
> resulted in much more stable Tomcat code. There is no such issue for TC
> 6.0.x (just a disagreement on the comet API, which we have already dealt
> with, and decided to let software-darwinism take it's course). Thus, there
> is really no reason for a "trunk" at this time, at least until the Servlet
> 3.0 spec comes out. If somebody wanted to make a [PROPOSAL] for major
> changes to the core TC 6.0.x API, then I can see setting up a "trunk" again.
> But there is no such animal lurking at this time.
No doubt, these were significant departures from their previous code.
But, are you suggesting that there is no need for trunk until there is an
idea you happen to champion? Present you with an idea that you like and
half the committee might decide to permit new development again?
This is certainly turning the idea of "show me the code" on it's head.
To give an example oft cited on this list, httpd maintains a trunk. It
might be released some day as-is, it might never be released. But it's
a staging ground to prove up an idea before injecting that idea into the
shipping stable version. It appears there is no such wilderness at
Tomcat.
Sandboxes don't cut it. It's very clear sandboxes are one-man-shows at
Tomcat. As such, they go against the concept of collaborative development
and don't belong at the foundation. If I misunderstand, and sandboxes are
shared spaces for proving concept-not-the-programmer, and everyone is
welcome at each sandbox to improve the proof of concept themselves, then
my objection is unfounded.
It seems the list wants very tight control on the stable 6.0 branch, so
your observation that trunk is irrelevant hasn't jived since I first read
this post (and I considered it's implications for a good 12 hrs).
It also brings up a real question of why was it so important to 'kill
trunk' if trunk, admittedly, is not relevant?
>> But without reestablishing a method for the committers to innovate, or
>> with continued/renewed territorial behaviors, this issue will likely
>> be noticed again by the board a few months from now as an issue in need
>> of a solution.
>
> I maintain that there is currently a very small barrier to "innovating" on
> Tomcat. We had one innovation that was shown to have a big whopping
> security hole in it, so it was withdrawn until a better patch can be made
> (i.e. the system worked). There were people (myself included) that would
> have preferred a modular patch (e.g. with httpd, I can configure it so that
> mod_alias isn't included with a few small edits, but the patch in question
> didn't allow for that, which was the complaints).
You are talking about one patch. Has Tomcat become so pathetic that there's
only one example of innovation in the past /x/ months to hold up as the one
true example?
Let's hope the rule systems that Tomcat debates and settles on reflect the
diversity of contributions, as opposed to a small handful of exceptions.
The fact that the rule systems themselves are being debated points me to
really wonder if there is any code debate here at all, or nothing more than
a clash of personalities which "changing the rules" is the simplest solution
to getting one's way?
In any case, the list continues to ponder what the meaning of the branches,
sandboxes etc all are, and I'll step out of this conversation (baring any
truly insane proposals) while the TC core community comes to terms with how
Tomcat can still prosper, and lose the perception of being a fiefdom of the
chosen few.
Bill
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Review model take 2
Posted by jean-frederic clere <jf...@gmail.com>.
Filip Hanik - Dev Lists wrote:
> Costin Manolache wrote:
>> On 9/20/07, Jim Jagielski <ji...@jagunet.com> wrote:
>>
>>> On Sep 19, 2007, at 10:55 PM, Bill Barker wrote:
>>>
>>>
>>>> TC 4.1.x and TC 5.5.x represented major changes to the core API, and
>>>> resulted in much more stable Tomcat code. There is no such issue
>>>> for TC
>>>> 6.0.x (just a disagreement on the comet API, which we have already
>>>> dealt
>>>> with, and decided to let software-darwinism take it's course).
>>>>
>>> When I suggested a TC 6.0 and 6.5 dual approach, Costin said:
>>>
>>> "Strong -1 on this. Done that - didn't work so good, and it
>>> doesn't solve
>>> the core problem - it's not about 'cutting edge' versus 'stable',..."
>>>
>>
>>
>>
>> Context needed :-)
>>
>> -1 was on having a TC6.5 as a way to resolve conflicts ( so some
>> people can
>> make broad
>> changes in one and some in other without having to
>> 'discuss'/argue/veto ).
>>
>> The transition between 5.5 to 6.0 ( AFAIK ) was based on '5.5 is mostly
>> frozen, only important
>> and select changes backported, all new activity on 6.0'.
>>
>> I also don't think a 6.5 is needed unless there is no huge
>> architecture and
>> API change, as it happened in 5.5->6.0,
>>
> well, we have the annotation changes needed for geronimo, that were not
> allowed in 6.0
> personally, I think that was enough to keep trunk alive.
> Let's say that I did have a huge architecture change, lets say, I want
> to swap out ByteChunk/CharChunk for ByteBuffer/CharBuffer and also use
> nio charset conversion,
> then doing that in trunk is not so appropriate either. So I will do that
> in sandbox, the right place for an experiment like that. Maybe it turns
> out that it worked perfectly, and we want to put that into Tomcat, we
> can't put it in 6.0, that would be insane, and we don't have a trunk, so
> where do we put it?
>
> Removing trunk, pretty much halted any chances for future innovation, as
> approved sandbox experiments have nowhere to go.
To my point of view the goal is/was not to remove trunk for ever.
The goal is/was to have a trunk where we all (or mostly all) agree on
what we want in it. It needs a road map for the future and may be rules
how to turn innovation in a stable product. It also needs more than 2
participants to prevent endless and useless disagreements.
Cheers
Jean-Frederic
>
>> but my 'strong -1' was for the reasons above. I don't mind having a
>> 6.5 -
>> if both Remy and Filip and all other
>> people who are actively developing move to 6.5 so changes get the right
>> review ( instead of 'that's my branch, that's yours' )
>>
> the "my" vs "your" should have never happened, and when those terms were
> coined, they should have been shutdown that very minute.
> I never believed in those terms for sure.
>
> Filip
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Review model take 2
Posted by Costin Manolache <co...@gmail.com>.
On 9/20/07, Filip Hanik - Dev Lists <de...@hanik.com> wrote:
> well, we have the annotation changes needed for geronimo, that were not
> allowed in 6.0
> personally, I think that was enough to keep trunk alive.
> Let's say that I did have a huge architecture change, lets say, I want
> to swap out ByteChunk/CharChunk for ByteBuffer/CharBuffer and also use
> nio charset conversion,
> then doing that in trunk is not so appropriate either. So I will do that
> in sandbox, the right place for an experiment like that. Maybe it turns
> out that it worked perfectly, and we want to put that into Tomcat, we
> can't put it in 6.0, that would be insane, and we don't have a trunk, so
> where do we put it?
For ByteChunk -> NIO - it's clearly an API chnge, so according to the new
proposal ( that seems to have a large enough majority and got clarified in
many
ways - probably can be put to a formal vote ): RTC. If a majority ( at least
3 +1,
more +1 than -1 ) think this should be done - we can discuss if this is big
enough to move from 6.0 to 6.5 ( I think it is - because will change a lot
of APIs ),
or if there are way to keep the old API working alongside with a new one (
backward
compatibiliy is quite important ).
Alternative answer: since the connector interface is heavily using
ByteChunk, you may
start it as a separate package from coyote ( nio-coyote ? ), add hook points
so you
can use nio-coyote connectors at the same time with coyote ones. Most of the
work
can be CTR, in 6.0 ( maybe a 'modules/' directory ). I'm not sure if this is
technically
feasible due to deps - but if I a vote comes up, I would vote for a proposal
that preserves
backward compat, and -1 if all existing connectors need to be rewritten.
For the others - again, you have the choice to implement them as a plugin,
CTR. If
it needs API/core changes - those need to be RTC and get majority. IMO if
you want
it done - minimizing API changes and doing most of the work in a component
has bigger
chances, but it's your proposal :-)
In all cases - it's a simple vote to decide if an API change or core
features gets in using RTC rules.
And it's also a simple vote to move from 6.0 to 6.5 ( and freeze 6.0 - all
new code/changes will go to 6.5 ).
Removing trunk, pretty much halted any chances for future innovation, as
> approved sandbox experiments have nowhere to go.
6.0 is really the place where active development on tomcat should happen
until a 6.5 proposal
is passed, so that's the real trunk ( no matter how it's called ).
The only issue is that "innovation" that affects API or core should be RTC -
i.e. requires
more than one person making arbitrary changes ( that may be valid and good -
but as with
any API change should be more controlled and have more support than a simple
'it works' )
And again - it's a simple vote to go either way, no need to fight or take
it personally -
every person has a different (and valid) opinion and may want to do things
his (better) way,
but needs to give up a bit for the sake of the others.
Costin
Re: Review model take 2
Posted by Filip Hanik - Dev Lists <de...@hanik.com>.
Costin Manolache wrote:
> On 9/20/07, Jim Jagielski <ji...@jagunet.com> wrote:
>
>> On Sep 19, 2007, at 10:55 PM, Bill Barker wrote:
>>
>>
>>> TC 4.1.x and TC 5.5.x represented major changes to the core API, and
>>> resulted in much more stable Tomcat code. There is no such issue
>>> for TC
>>> 6.0.x (just a disagreement on the comet API, which we have already
>>> dealt
>>> with, and decided to let software-darwinism take it's course).
>>>
>> When I suggested a TC 6.0 and 6.5 dual approach, Costin said:
>>
>> "Strong -1 on this. Done that - didn't work so good, and it
>> doesn't solve
>> the core problem - it's not about 'cutting edge' versus 'stable',..."
>>
>
>
>
> Context needed :-)
>
> -1 was on having a TC6.5 as a way to resolve conflicts ( so some people can
> make broad
> changes in one and some in other without having to 'discuss'/argue/veto ).
>
> The transition between 5.5 to 6.0 ( AFAIK ) was based on '5.5 is mostly
> frozen, only important
> and select changes backported, all new activity on 6.0'.
>
> I also don't think a 6.5 is needed unless there is no huge architecture and
> API change, as it happened in 5.5->6.0,
>
well, we have the annotation changes needed for geronimo, that were not
allowed in 6.0
personally, I think that was enough to keep trunk alive.
Let's say that I did have a huge architecture change, lets say, I want
to swap out ByteChunk/CharChunk for ByteBuffer/CharBuffer and also use
nio charset conversion,
then doing that in trunk is not so appropriate either. So I will do that
in sandbox, the right place for an experiment like that. Maybe it turns
out that it worked perfectly, and we want to put that into Tomcat, we
can't put it in 6.0, that would be insane, and we don't have a trunk, so
where do we put it?
Removing trunk, pretty much halted any chances for future innovation, as
approved sandbox experiments have nowhere to go.
> but my 'strong -1' was for the reasons above. I don't mind having a 6.5 -
> if both Remy and Filip and all other
> people who are actively developing move to 6.5 so changes get the right
> review ( instead of 'that's my branch, that's yours' )
>
the "my" vs "your" should have never happened, and when those terms were
coined, they should have been shutdown that very minute.
I never believed in those terms for sure.
Filip
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Review model take 2
Posted by Jim Jagielski <ji...@jaguNET.com>.
On Sep 20, 2007, at 9:57 AM, Costin Manolache wrote:
> On 9/20/07, Jim Jagielski <ji...@jagunet.com> wrote:
>>
>>
>> On Sep 19, 2007, at 10:55 PM, Bill Barker wrote:
>>
>>>
>>> TC 4.1.x and TC 5.5.x represented major changes to the core API, and
>>> resulted in much more stable Tomcat code. There is no such issue
>>> for TC
>>> 6.0.x (just a disagreement on the comet API, which we have already
>>> dealt
>>> with, and decided to let software-darwinism take it's course).
>>
>> When I suggested a TC 6.0 and 6.5 dual approach, Costin said:
>>
>> "Strong -1 on this. Done that - didn't work so good, and it
>> doesn't solve
>> the core problem - it's not about 'cutting edge' versus
>> 'stable',..."
>
>
>
> Context needed :-)
>
> -1 was on having a TC6.5 as a way to resolve conflicts ( so some
> people can
> make broad
> changes in one and some in other without having to 'discuss'/argue/
> veto ).
>
> The transition between 5.5 to 6.0 ( AFAIK ) was based on '5.5 is
> mostly
> frozen, only important
> and select changes backported, all new activity on 6.0'.
>
> I also don't think a 6.5 is needed unless there is no huge
> architecture and
> API change, as it happened in 5.5->6.0,
> but my 'strong -1' was for the reasons above. I don't mind having
> a 6.5 -
> if both Remy and Filip and all other
> people who are actively developing move to 6.5 so changes get the
> right
> review ( instead of 'that's my branch, that's yours' )
>
Umm... the issue is/was 4.0/4.1 and 5.0/5.5 not
any 5.x->6.x stuff. The major number has nothing to
do with it. Who said anything about the major number
transition? Maybe that's why you voted -1 because I
didn't explain the idea more clearly... sorry!
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Review model take 2
Posted by Costin Manolache <co...@gmail.com>.
On 9/20/07, Jim Jagielski <ji...@jagunet.com> wrote:
>
>
> On Sep 19, 2007, at 10:55 PM, Bill Barker wrote:
>
> >
> > TC 4.1.x and TC 5.5.x represented major changes to the core API, and
> > resulted in much more stable Tomcat code. There is no such issue
> > for TC
> > 6.0.x (just a disagreement on the comet API, which we have already
> > dealt
> > with, and decided to let software-darwinism take it's course).
>
> When I suggested a TC 6.0 and 6.5 dual approach, Costin said:
>
> "Strong -1 on this. Done that - didn't work so good, and it
> doesn't solve
> the core problem - it's not about 'cutting edge' versus 'stable',..."
Context needed :-)
-1 was on having a TC6.5 as a way to resolve conflicts ( so some people can
make broad
changes in one and some in other without having to 'discuss'/argue/veto ).
The transition between 5.5 to 6.0 ( AFAIK ) was based on '5.5 is mostly
frozen, only important
and select changes backported, all new activity on 6.0'.
I also don't think a 6.5 is needed unless there is no huge architecture and
API change, as it happened in 5.5->6.0,
but my 'strong -1' was for the reasons above. I don't mind having a 6.5 -
if both Remy and Filip and all other
people who are actively developing move to 6.5 so changes get the right
review ( instead of 'that's my branch, that's yours' )
Costin
Re: Review model take 2
Posted by Jim Jagielski <ji...@jaguNET.com>.
On Sep 19, 2007, at 10:55 PM, Bill Barker wrote:
>
> TC 4.1.x and TC 5.5.x represented major changes to the core API, and
> resulted in much more stable Tomcat code. There is no such issue
> for TC
> 6.0.x (just a disagreement on the comet API, which we have already
> dealt
> with, and decided to let software-darwinism take it's course).
When I suggested a TC 6.0 and 6.5 dual approach, Costin said:
"Strong -1 on this. Done that - didn't work so good, and it
doesn't solve
the core problem - it's not about 'cutting edge' versus 'stable',..."
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Review model take 2
Posted by Bill Barker <wb...@wilshire.com>.
"William A. Rowe, Jr." <wr...@rowe-clan.net> wrote in message
news:46F1B233.3050205@rowe-clan.net...
> jean-frederic clere wrote:
>>
>> Now for me that just makes another chapter in the "STATUS" file:
>> "PATCHES being discussed". After a week those patches should be accepted
>> or reverted. Reverted patches and corresponding discussions should stay
>> in the "STATUS" until a solution is found. I would keep a passing margin
>> of +3.
>
> A higher bar to add a feature than to release the software? Plainly
> absurd.
>
> Majority is more than sufficient for almost any decision (more + than -)
> so long as you have at least three affirmative votes. The only exception
> would be to undoing the decision of the PMC, such as booting a person from
> the project or 'unreleasing' a release (not that this would make any
> sense).
> Those sorts of decisions *need* a supermajority (60 - 75% or even
> unanimous
> decision, depending on what rules the committee follows) to undo what the
> majority had settled on before.
>
> That is unless you plan to shutter the project, which is what much of this
> discussion seems to be about. Set up as many obstacles to changing
> Tomcat,
> until Tomcat stagnates entirely, and surrenders to that Glassfish thing?
>
> If the project wants to remain relevant, it needs a healthy community,
> which means attracting instead of repulsing people, and it needs. And
> it needs to provide an opportunity for people to innovate, not many of
> the folks here suck on the corporate tit for their camping at Tomcat, and
> are "happy" to do allot of nothing. Creativity is the energy behind the
> success of ASF projects. Deny your contributors the opportunity to solve
> problems creatively, and you might as well hang out the "Closed" sign out
> on the http://tomcat.apache.org/ page already.
>
> All that said, the topic of "no more trunk" came up at the board meeting
> today. I gave a very brief background and suggested that some of the
> renewed interest by folks who had been silent throughout the Filip-Remy
> trunk war is a hopeful sign; with renewed interest the project is very
> likely to be able to manage itself successfully through these personal
> and stylistic disagreements; the board is satisfied to see the project
> try to work out these issues themselves as long as development once again
> is encouraged.
>
TC 4.1.x and TC 5.5.x represented major changes to the core API, and
resulted in much more stable Tomcat code. There is no such issue for TC
6.0.x (just a disagreement on the comet API, which we have already dealt
with, and decided to let software-darwinism take it's course). Thus, there
is really no reason for a "trunk" at this time, at least until the Servlet
3.0 spec comes out. If somebody wanted to make a [PROPOSAL] for major
changes to the core TC 6.0.x API, then I can see setting up a "trunk" again.
But there is no such animal lurking at this time.
> But without reestablishing a method for the committers to innovate, or
> with continued/renewed territorial behaviors, this issue will likely
> be noticed again by the board a few months from now as an issue in need
> of a solution.
>
I maintain that there is currently a very small barrier to "innovating" on
Tomcat. We had one innovation that was shown to have a big whopping
security hole in it, so it was withdrawn until a better patch can be made
(i.e. the system worked). There were people (myself included) that would
have preferred a modular patch (e.g. with httpd, I can configure it so that
mod_alias isn't included with a few small edits, but the patch in question
didn't allow for that, which was the complaints).
> Bill
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Review model take 2
Posted by jean-frederic clere <jf...@gmail.com>.
William A. Rowe, Jr. wrote:
> jean-frederic clere wrote:
>> William A. Rowe, Jr. wrote:
>>
>>> If you are talking about at least 3 +1's, more + than -, then that's being
>>> realistic. JFC - did you really mean a margin?
>> Yep that was what I meant at that time.
>
> I'm really sorry I misunderstood you Jean-Frederic, I came from some financial
> coding where I learned margin/markup/profit aren't the same formula after all :)
No problems ;-)
We must find a way to solve conflicts and have rules for that. The rules
must as prefect as possible so that there isn't any misunderstanding
and acceptable for the community.
Cheers
Jean-Frederic
>
> Bill
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Review model take 2
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
jean-frederic clere wrote:
> William A. Rowe, Jr. wrote:
>
>> If you are talking about at least 3 +1's, more + than -, then that's being
>> realistic. JFC - did you really mean a margin?
>
> Yep that was what I meant at that time.
I'm really sorry I misunderstood you Jean-Frederic, I came from some financial
coding where I learned margin/markup/profit aren't the same formula after all :)
Bill
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Review model take 2
Posted by jean-frederic clere <jf...@gmail.com>.
William A. Rowe, Jr. wrote:
> Remy Maucherat wrote:
>> William A. Rowe, Jr. wrote:
>>> jean-frederic clere wrote:
>>>> Now for me that just makes another chapter in the "STATUS" file:
>>>> "PATCHES being discussed". After a week those patches should be accepted
>>>> or reverted. Reverted patches and corresponding discussions should stay
>>>> in the "STATUS" until a solution is found. I would keep a passing margin
>>>> of +3.
>>> A higher bar to add a feature than to release the software? Plainly
>>> absurd.
>> Features additions are not mentioned in my proposal. We also use a +3
>> vote for releases.
>
> Maybe we are misusing words. A passing margin of +3 means three more +1's
> than -1's; that means if you had 2 -1's you would seek 5 +1's to keep going
> over the objection. That's what I referred to as absurd.
I don't see why it is absurd when you have 2 -1 and 5 +1 but well 5 -1
and 8 +1 starts to show why you think it "absurd". So I think that "
at least 3 +1's and more + than -" is acceptable for me.
May be one additional duty for committers could be to cast vote on
proposals when the PMC Chair requests it to reach enough votes so that a
majority express their view.
>
> If you are talking about at least 3 +1's, more + than -, then that's being
> realistic. JFC - did you really mean a margin?
Yep that was what I meant at that time.
Cheers
Jean-Frederic
>
> Bill
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Review model take 2
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
Remy Maucherat wrote:
> William A. Rowe, Jr. wrote:
>> jean-frederic clere wrote:
>>> Now for me that just makes another chapter in the "STATUS" file:
>>> "PATCHES being discussed". After a week those patches should be accepted
>>> or reverted. Reverted patches and corresponding discussions should stay
>>> in the "STATUS" until a solution is found. I would keep a passing margin
>>> of +3.
>>
>> A higher bar to add a feature than to release the software? Plainly
>> absurd.
>
> Features additions are not mentioned in my proposal. We also use a +3
> vote for releases.
Maybe we are misusing words. A passing margin of +3 means three more +1's
than -1's; that means if you had 2 -1's you would seek 5 +1's to keep going
over the objection. That's what I referred to as absurd.
If you are talking about at least 3 +1's, more + than -, then that's being
realistic. JFC - did you really mean a margin?
Bill
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Review model take 2
Posted by Remy Maucherat <re...@apache.org>.
William A. Rowe, Jr. wrote:
> jean-frederic clere wrote:
>> Now for me that just makes another chapter in the "STATUS" file:
>> "PATCHES being discussed". After a week those patches should be accepted
>> or reverted. Reverted patches and corresponding discussions should stay
>> in the "STATUS" until a solution is found. I would keep a passing margin
>> of +3.
>
> A higher bar to add a feature than to release the software? Plainly absurd.
The patches which would be put under review are:
- API or configuration changing patches
- those which are found to be risky, or simply in need of significant
improvements
Features additions are not mentioned in my proposal. We also use a +3
vote for releases.
Rémy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Review model take 2
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
Costin Manolache wrote:
>
> What I see as a problem is not involving the community in the decision
> making about basic features.
>
> Let's make it clear - adding new features or replacing/improving any
> component in tomcat
> should stay CTR and should be encouraged and supported. Anyone can create
> Valves, Connectors,
> Jndi implementations, class loaders or almost anything else that can be
> plugged into tomcat
> via config file - and a change to add more hook points shouldn't be hard to
> get in.
>
> However - for new features that want to be bundled with tomcat, or for
> important or
> controversial changes ( defined as 'no consensus' - and one person in
> disagreement means
> no consensus ) - a majority vote should resolve the question and avoid any
> personal or one-on-one fights.
>
> Consensus is simple to determine - and so is lack of consensus for any
> feature. If Remy and Filip
> ( and all other committers who care about something ) are in consensus -
> done. If there is
> doubt - involving and asking more people seems the right solution.
++1
> I think it is a big mistake to use the sandbox as a way to avoid
> confrontation - or to waste time
> debating subjective things like what is better among 2 not-so-obviously bad
> solutions ( which is
> what causes most hurt feelings ). Implement any feature you want in a
> module, pack it as a jar
> with instructions on how to use it, get 3 +1s to release it - and after it
> gets some testing and
> traction - request it to be part of standard distro or the default
> JNDI/Connector/ClassLoader/etc.
> Easy, no conflicts needed, good for both tomcat and the feature itself. If
> someone else can
> implement it in a better way - new vote will get the other one.
Well said, all the way around.
Thanks,
Bill
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Review model take 2
Posted by Remy Maucherat <re...@apache.org>.
Costin Manolache wrote:
> Let's make it clear - adding new features or replacing/improving any
> component in tomcat
> should stay CTR and should be encouraged and supported. Anyone can create
> Valves, Connectors,
> Jndi implementations, class loaders or almost anything else that can be
> plugged into tomcat
> via config file - and a change to add more hook points shouldn't be hard to
> get in.
Changes to core components are not mentioned in my proposal, but they
could be put under review if needed. Obviously, it seems such changes
would be more likely to be put under review, but I don't see a need to
make it automatic.
In an earlier email, you mentioned module hooks as an exception. This is
interesting, but risky, I think. Hooks is usually a rather important
API, and for example, I would think extending the Valve API should be
subject to review.
> I think it is a big mistake to use the sandbox as a way to avoid
> confrontation - or to waste time
> debating subjective things like what is better among 2 not-so-obviously bad
> solutions ( which is
> what causes most hurt feelings ). Implement any feature you want in a
> module, pack it as a jar
> with instructions on how to use it, get 3 +1s to release it - and after it
> gets some testing and
> traction - request it to be part of standard distro or the default
> JNDI/Connector/ClassLoader/etc.
> Easy, no conflicts needed, good for both tomcat and the feature itself. If
> someone else can
> implement it in a better way - new vote will get the other one.
It's up to the developers to present changes in the best possible way, I
think.
Rémy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Review model take 2
Posted by Costin Manolache <co...@gmail.com>.
I agree that a simple majority should be enough for any API change or any
feature,
but I don't think this was the spirit of the proposal.
What I see as a problem is not involving the community in the decision
making about
basic features.
Let's make it clear - adding new features or replacing/improving any
component in tomcat
should stay CTR and should be encouraged and supported. Anyone can create
Valves, Connectors,
Jndi implementations, class loaders or almost anything else that can be
plugged into tomcat
via config file - and a change to add more hook points shouldn't be hard to
get in.
However - for new features that want to be bundled with tomcat, or for
important or
controversial changes ( defined as 'no consensus' - and one person in
disagreement means
no consensus ) - a majority vote should resolve the question and avoid any
personal or one-on-one
fights.
Consensus is simple to determine - and so is lack of consensus for any
feature. If Remy and Filip
( and all other committers who care about something ) are in consensus -
done. If there is
doubt - involving and asking more people seems the right solution.
I think it is a big mistake to use the sandbox as a way to avoid
confrontation - or to waste time
debating subjective things like what is better among 2 not-so-obviously bad
solutions ( which is
what causes most hurt feelings ). Implement any feature you want in a
module, pack it as a jar
with instructions on how to use it, get 3 +1s to release it - and after it
gets some testing and
traction - request it to be part of standard distro or the default
JNDI/Connector/ClassLoader/etc.
Easy, no conflicts needed, good for both tomcat and the feature itself. If
someone else can
implement it in a better way - new vote will get the other one.
Costin
On 9/19/07, William A. Rowe, Jr. <wr...@rowe-clan.net> wrote:
>
> jean-frederic clere wrote:
> >
> > Now for me that just makes another chapter in the "STATUS" file:
> > "PATCHES being discussed". After a week those patches should be accepted
> > or reverted. Reverted patches and corresponding discussions should stay
> > in the "STATUS" until a solution is found. I would keep a passing margin
> > of +3.
>
> A higher bar to add a feature than to release the software? Plainly
> absurd.
>
> Majority is more than sufficient for almost any decision (more + than -)
> so long as you have at least three affirmative votes. The only exception
> would be to undoing the decision of the PMC, such as booting a person from
> the project or 'unreleasing' a release (not that this would make any
> sense).
> Those sorts of decisions *need* a supermajority (60 - 75% or even
> unanimous
> decision, depending on what rules the committee follows) to undo what the
> majority had settled on before.
>
> That is unless you plan to shutter the project, which is what much of this
> discussion seems to be about. Set up as many obstacles to changing
> Tomcat,
> until Tomcat stagnates entirely, and surrenders to that Glassfish thing?
>
> If the project wants to remain relevant, it needs a healthy community,
> which means attracting instead of repulsing people, and it needs. And
> it needs to provide an opportunity for people to innovate, not many of
> the folks here suck on the corporate tit for their camping at Tomcat, and
> are "happy" to do allot of nothing. Creativity is the energy behind the
> success of ASF projects. Deny your contributors the opportunity to solve
> problems creatively, and you might as well hang out the "Closed" sign out
> on the http://tomcat.apache.org/ page already.
>
> All that said, the topic of "no more trunk" came up at the board meeting
> today. I gave a very brief background and suggested that some of the
> renewed interest by folks who had been silent throughout the Filip-Remy
> trunk war is a hopeful sign; with renewed interest the project is very
> likely to be able to manage itself successfully through these personal
> and stylistic disagreements; the board is satisfied to see the project
> try to work out these issues themselves as long as development once again
> is encouraged.
>
> But without reestablishing a method for the committers to innovate, or
> with continued/renewed territorial behaviors, this issue will likely
> be noticed again by the board a few months from now as an issue in need
> of a solution.
>
> Bill
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
>
Re: Review model take 2
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
jean-frederic clere wrote:
>
> Now for me that just makes another chapter in the "STATUS" file:
> "PATCHES being discussed". After a week those patches should be accepted
> or reverted. Reverted patches and corresponding discussions should stay
> in the "STATUS" until a solution is found. I would keep a passing margin
> of +3.
A higher bar to add a feature than to release the software? Plainly absurd.
Majority is more than sufficient for almost any decision (more + than -)
so long as you have at least three affirmative votes. The only exception
would be to undoing the decision of the PMC, such as booting a person from
the project or 'unreleasing' a release (not that this would make any sense).
Those sorts of decisions *need* a supermajority (60 - 75% or even unanimous
decision, depending on what rules the committee follows) to undo what the
majority had settled on before.
That is unless you plan to shutter the project, which is what much of this
discussion seems to be about. Set up as many obstacles to changing Tomcat,
until Tomcat stagnates entirely, and surrenders to that Glassfish thing?
If the project wants to remain relevant, it needs a healthy community,
which means attracting instead of repulsing people, and it needs. And
it needs to provide an opportunity for people to innovate, not many of
the folks here suck on the corporate tit for their camping at Tomcat, and
are "happy" to do allot of nothing. Creativity is the energy behind the
success of ASF projects. Deny your contributors the opportunity to solve
problems creatively, and you might as well hang out the "Closed" sign out
on the http://tomcat.apache.org/ page already.
All that said, the topic of "no more trunk" came up at the board meeting
today. I gave a very brief background and suggested that some of the
renewed interest by folks who had been silent throughout the Filip-Remy
trunk war is a hopeful sign; with renewed interest the project is very
likely to be able to manage itself successfully through these personal
and stylistic disagreements; the board is satisfied to see the project
try to work out these issues themselves as long as development once again
is encouraged.
But without reestablishing a method for the committers to innovate, or
with continued/renewed territorial behaviors, this issue will likely
be noticed again by the board a few months from now as an issue in need
of a solution.
Bill
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Review model take 2
Posted by jean-frederic clere <jf...@gmail.com>.
Remy Maucherat wrote:
> jean-frederic clere wrote:
>> Well I see at least 3 reasons to revert it:
>> - Prevent accidental inclusion in a release.
>> - Allow a more easy testing and evaluation of a another patch that fixes
>> the same thing.
>> - Force the community to look for another solution.
>
> As much as possible, I would like to avoid reverting a patch until the
> review is concluded (or there is passing review on a patch which
> supersedes it), as it wastes time and is annoying to do.
Ok. Reverting it doesn't force the ones that disagree to react quicky
once reverted.
Now for me that just makes another chapter in the "STATUS" file:
"PATCHES being discussed". After a week those patches should be accepted
or reverted. Reverted patches and corresponding discussions should stay
in the "STATUS" until a solution is found. I would keep a passing margin
of +3.
Cheers
Jean-Frederic
> The main other
> issues are to determine:
> - how long a review should last (most likely, the usual one week would do)
> - the passing margin (+3 could be +2, for example)
>
> Rémy
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Review model take 2
Posted by Remy Maucherat <re...@apache.org>.
jean-frederic clere wrote:
> Well I see at least 3 reasons to revert it:
> - Prevent accidental inclusion in a release.
> - Allow a more easy testing and evaluation of a another patch that fixes
> the same thing.
> - Force the community to look for another solution.
As much as possible, I would like to avoid reverting a patch until the
review is concluded (or there is passing review on a patch which
supersedes it), as it wastes time and is annoying to do. The main other
issues are to determine:
- how long a review should last (most likely, the usual one week would do)
- the passing margin (+3 could be +2, for example)
Rémy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Review model take 2
Posted by Filip Hanik - Dev Lists <de...@hanik.com>.
Remy Maucherat wrote:
> Jim Jagielski wrote:
>> On Sep 19, 2007, at 10:28 PM, Bill Barker wrote:
>>
>>> And, yet again, Filip chooses to question the validity of the vote,
>>> instead
>>> of discussing ideas :(.
>>
>> How can one vote when the details of what one is voting for
>> are still being discussed? Or, on the other hand, why call
>
> There is "draft" written in the subject of the email.
>
>> for a (premature) vote if one still wants to have a discussion
>> about ideas?
>
> This has been under discussion for weeks, I would say it is time to
> wrap things up at some point.
>
>> Quite frankly, the 2 normal methods of doing code development
>> are seen as bad for the following reasons:
>>
>> 1. CTR:
>> Seen as bad because it allows for someone to go off
>> on their own tangent.
>> How it really works: Anyone committing code during this
>> process must be aware that a later-on review of the
>> patch may require it to be either patched, substantially
>> modified or removed all together. If the patch has
>> far reaching effects, it would be best to, before
>> applying, discussing it on dev@ and achieving some sort
>> of consensus (even lazy) that you aren't wasting your
>> time. But you must be prepared to, worse case, back it
>> out if need be. This implies, of course, that the rationale
>> for the veto is justifiably technical, with a technical
>> and objective basis. Enables faster development on a
>> community codebase.
>
> Yes, but the only thing that really happens is a flame war to debate
> if the veto (which is a far too broad and absolute tool for review) is
> valid. So maybe it works in some situations, but at this point I don't
> see how a generic gentler review mechanism would hurt.
>
>> 2. RTC:
>> Seen as bad because it slows development down.
>
> Actually, nobody mentions this anymore. The only remaining specific
> "issue" that was mentioned is being able to block a particular change.
> As far as I am concerned, this is not any different from a veto,
> except that more people would have to review something negatively to
> block things up.
>
>> How it really works: Avoids the possible huge disruption
>> when a patch needs to be reversed. Ensures sufficient
>> community acceptance of implementation and patch to
>> justify the effort in creating it. Ensures stable
>> branch remains stable.
>>
>> If there was a better underlying feeling of trust here, as
>> well as concerted effort to make development communal as well
>> as not abuse the veto power, then a lot of this discussion
>> and crafting of hybrid development methods with explicit
>> rules would likely not be required.
>
> This is true. For starters, as I stated on the PMC list, I think that
> one person should not remain as a committer (and I will obviously
> ignore all his posts until further notice).
interesting, and this "new process" is supposed to solve the attitude
deficiency described in the line above.
fundamentally if you have a personal issue, there are no means that the
issue will be solved until you move on and put it past you.
so you tried to kick me out as a committer, and that didn't work for
you, too bad, maybe it would have been easier that way, but it wasn't my
call.
But hey, it didn't work out your way, deal with it in an appropriate
way. I'm one of the few who's stepped up and challenged the flood of
vetoes that comes from your corner, most of them with simple one line
personal statement behind them, and for that, you think I no longer
belong in the Tomcat community. That would make the community
hierarchical, wouldn't it?
There are two things that can happen
1. Encourage more discussion - see my other email
For this to happen, the responses need to be thought out. If you
think about it, why people are not discussing it, could be cause they
dont want to deal with the one line responses
2. Vetos need to be done in the ASF way, not in the old Tomcat way.
Filip
> There's also a general behavior of not discussing fairly significant
> changes before committing (even on release branches). If general good
> behavior rules and processes were not needed, the ASF would have none
> and rely exclusively on good will. It's obviously not the case, and
> we're here discussing a review model to better address the project's
> specific needs.
>
> Rémy
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Review model take 2
Posted by Remy Maucherat <re...@apache.org>.
Jim Jagielski wrote:
> On Sep 19, 2007, at 10:28 PM, Bill Barker wrote:
>
>> And, yet again, Filip chooses to question the validity of the vote,
>> instead
>> of discussing ideas :(.
>
> How can one vote when the details of what one is voting for
> are still being discussed? Or, on the other hand, why call
There is "draft" written in the subject of the email.
> for a (premature) vote if one still wants to have a discussion
> about ideas?
This has been under discussion for weeks, I would say it is time to wrap
things up at some point.
> Quite frankly, the 2 normal methods of doing code development
> are seen as bad for the following reasons:
>
> 1. CTR:
> Seen as bad because it allows for someone to go off
> on their own tangent.
> How it really works: Anyone committing code during this
> process must be aware that a later-on review of the
> patch may require it to be either patched, substantially
> modified or removed all together. If the patch has
> far reaching effects, it would be best to, before
> applying, discussing it on dev@ and achieving some sort
> of consensus (even lazy) that you aren't wasting your
> time. But you must be prepared to, worse case, back it
> out if need be. This implies, of course, that the rationale
> for the veto is justifiably technical, with a technical
> and objective basis. Enables faster development on a
> community codebase.
Yes, but the only thing that really happens is a flame war to debate if
the veto (which is a far too broad and absolute tool for review) is
valid. So maybe it works in some situations, but at this point I don't
see how a generic gentler review mechanism would hurt.
> 2. RTC:
> Seen as bad because it slows development down.
Actually, nobody mentions this anymore. The only remaining specific
"issue" that was mentioned is being able to block a particular change.
As far as I am concerned, this is not any different from a veto, except
that more people would have to review something negatively to block
things up.
> How it really works: Avoids the possible huge disruption
> when a patch needs to be reversed. Ensures sufficient
> community acceptance of implementation and patch to
> justify the effort in creating it. Ensures stable
> branch remains stable.
>
> If there was a better underlying feeling of trust here, as
> well as concerted effort to make development communal as well
> as not abuse the veto power, then a lot of this discussion
> and crafting of hybrid development methods with explicit
> rules would likely not be required.
This is true. For starters, as I stated on the PMC list, I think that
one person should not remain as a committer (and I will obviously ignore
all his posts until further notice). There's also a general behavior of
not discussing fairly significant changes before committing (even on
release branches). If general good behavior rules and processes were not
needed, the ASF would have none and rely exclusively on good will. It's
obviously not the case, and we're here discussing a review model to
better address the project's specific needs.
Rémy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Review model take 2
Posted by Jim Jagielski <ji...@jaguNET.com>.
On Sep 19, 2007, at 10:28 PM, Bill Barker wrote:
>
> And, yet again, Filip chooses to question the validity of the vote,
> instead
> of discussing ideas :(.
How can one vote when the details of what one is voting for
are still being discussed? Or, on the other hand, why call
for a (premature) vote if one still wants to have a discussion
about ideas?
Quite frankly, the 2 normal methods of doing code development
are seen as bad for the following reasons:
1. CTR:
Seen as bad because it allows for someone to go off
on their own tangent.
How it really works: Anyone committing code during this
process must be aware that a later-on review of the
patch may require it to be either patched, substantially
modified or removed all together. If the patch has
far reaching effects, it would be best to, before
applying, discussing it on dev@ and achieving some sort
of consensus (even lazy) that you aren't wasting your
time. But you must be prepared to, worse case, back it
out if need be. This implies, of course, that the rationale
for the veto is justifiably technical, with a technical
and objective basis. Enables faster development on a
community codebase.
2. RTC:
Seen as bad because it slows development down.
How it really works: Avoids the possible huge disruption
when a patch needs to be reversed. Ensures sufficient
community acceptance of implementation and patch to
justify the effort in creating it. Ensures stable
branch remains stable.
If there was a better underlying feeling of trust here, as
well as concerted effort to make development communal as well
as not abuse the veto power, then a lot of this discussion
and crafting of hybrid development methods with explicit
rules would likely not be required.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Review model take 2
Posted by Jim Jagielski <ji...@jaguNET.com>.
On Sep 19, 2007, at 10:43 PM, William A. Rowe, Jr. wrote:
>
> If Joe says "this feature isn't going to be acceptable because Y",
> well
> then there isn't much to discuss at that point, and it probably
> should be
> backed out right away while the basic idea is debated.
>
Certainly it depends on what "Y" is though.
If "Y" is 'it breaks the servlet spec' then yeah.
If "Y" is 'I really don't like this because I think it's
stupid' then it's a whole different ball of wax.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Review model take 2
Posted by Bill Barker <wb...@wilshire.com>.
"William A. Rowe, Jr." <wr...@rowe-clan.net> wrote in message
news:46F1DE56.8030703@rowe-clan.net...
> Bill Barker wrote:
>>
>> Remy was being really nice to the community by not requiring a vetoed
>> patch
>> to be withdrawn. Personally, I would go with j-f-c's position, and
>> withdraw
>> a vetoed patch immediately (and have done so on several occations, even
>> when
>> I got to re-apply it after enough discussion took place on the list).
>> However, I'll go with whatever the community consensus is on this point.
>
> But isn't that statement too broad (to apply to trunk, I agree that in a
> ready-to-release anytime sort of branch, disputed things should disappear
> for a while)...
>
There is no trunk in Tomcat :), and likely won't be until the sooner of a
[PROPOSAL] or the Servlet 3.0 spec is published.
As I said, personally I revert patches on a veto, pending discussion. But
I'm going to back the majority on this point whichever way it goes.
> It's in the context. If Joe suggests "hey, -1 to the way you presented
> that, if you fix X you have my support" then it should stick a round a
> while and let them sort it out.
>
> If Joe says "this feature isn't going to be acceptable because Y", well
> then there isn't much to discuss at that point, and it probably should be
> backed out right away while the basic idea is debated.
>
> Clear A/B options sometimes aren't that effective.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Review model take 2
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
Bill Barker wrote:
>
> Remy was being really nice to the community by not requiring a vetoed patch
> to be withdrawn. Personally, I would go with j-f-c's position, and withdraw
> a vetoed patch immediately (and have done so on several occations, even when
> I got to re-apply it after enough discussion took place on the list).
> However, I'll go with whatever the community consensus is on this point.
But isn't that statement too broad (to apply to trunk, I agree that in a
ready-to-release anytime sort of branch, disputed things should disappear
for a while)...
It's in the context. If Joe suggests "hey, -1 to the way you presented
that, if you fix X you have my support" then it should stick a round a
while and let them sort it out.
If Joe says "this feature isn't going to be acceptable because Y", well
then there isn't much to discuss at that point, and it probably should be
backed out right away while the basic idea is debated.
Clear A/B options sometimes aren't that effective.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Review model take 2
Posted by jean-frederic clere <jf...@gmail.com>.
Filip Hanik - Dev Lists wrote:
> Bill Barker wrote:
>> "Filip Hanik - Dev Lists" <de...@hanik.com> wrote in message
>> news:46F12965.2080404@hanik.com...
>>
>>> jean-frederic clere wrote:
>>>
>>>> Remy Maucherat wrote:
>>>>
>>>>
>>>>> jean-frederic clere wrote:
>>>>>
>>>>>
>>>>>> Filip Hanik - Dev Lists wrote:
>>>>>>
>>>>>>
>>>>>>> Remy Maucherat wrote:
>>>>>>>
>>>>>>>
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> Another more precise draft.
>>>>>>>>
>>>>>>>> Patches which would go to review would be:
>>>>>>>> - API changing patches (any protected or above signature change) on
>>>>>>>> APIs which are accessible to the user either from confirguration or
>>>>>>>> programmatically
>>>>>>>>
>>>>>>>>
>>>>>>> yes, makes sense
>>>>>>>
>>>>>>>
>>>>>>>> - any other commit for which a committer asks for the RTC procedure
>>>>>>>> should be rollbacked if it hinders concurrent work or is to be
>>>>>>>> included in a release tag, and go through the RTC procedure
>>>>>>>>
>>>>>>>>
>>>>>>> -1. There is a huge risk for "I simply don't like it, revert it".
>>>>>>> Anything that is to be rolled back, should be backed up by a
>>>>>>> technical
>>>>>>> reason. So in this case, how do you define "it hinders concurrent
>>>>>>> work".
>>>>>>> Either we do RTC or we don't, but having a vague definition in
>>>>>>> between,
>>>>>>> doesn't make sense.
>>>>>>>
>>>>>>>
>>>>>> That is not: "I simply don't like it, revert it" that is "I think it
>>>>>> needs review, revert it and let's discuss it".
>>>>>> I would proposed that the one that does the -1 should come with
>>>>>> another
>>>>>> fix in few days for a fix for a PR, another proposal for API/conf
>>>>>> changes and participate to the discussion on the -1 otherwise the -1
>>>>>> would become is invalid.
>>>>>>
>>>>>>
>>>>> The patch does not need to be reverted when under review, except if
>>>>> there's a need to tag a release or something similar.
>>>>>
>>>>>
>>>> Well I see at least 3 reasons to revert it:
>>>> - Prevent accidental inclusion in a release.
>>>> - Allow a more easy testing and evaluation of a another patch that
>>>> fixes
>>>> the same thing.
>>>> - Force the community to look for another solution.
>>>>
>>>>
>>> so to me this is spanking clear, that the process is vague, and
>>> before anything like this is implemented, it should be as black and
>>> white as RTC and CTR if it's gonna work
>>> at this point, the vote doesn't make sense, as it is obvious folks
>>> aren't clear on the process being voted on.
>>>
>>>
>>
>> And, yet again, Filip chooses to question the validity of the vote,
>> instead of discussing ideas :(. Now I feel insulted as well, since
>> I'm fully aware on the process being voted on. But if I lived with
>> Jon in the same community, I can live with Filip ;-).
>>
> how can we vote, if the thread goes into discussion. The ASF clearly has
> to methods of developing, CTR or RTC,
> So there are two questions here
> 1. Why do we need something in between
> 2. This is the third time around this topic has been discussed, and
> folks are still unclear on the process or the desire thereof, you might
> be clear, but me, and others based on the thread for sure aren't. The
> new model is not black and white, but it would have to be in order to work.
If we are discussing how we should develop it is because CTR shows it
limits... It doesn't define clearly how to handle a -1 on a commit and
that is why the discussion turns into the validity of the -1 instead
discussing the code.
Cheers
Jean-Frederic
+++ CUT +++
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Review model take 2
Posted by Filip Hanik - Dev Lists <de...@hanik.com>.
Bill Barker wrote:
> "Filip Hanik - Dev Lists" <de...@hanik.com> wrote in message
> news:46F12965.2080404@hanik.com...
>
>> jean-frederic clere wrote:
>>
>>> Remy Maucherat wrote:
>>>
>>>
>>>> jean-frederic clere wrote:
>>>>
>>>>
>>>>> Filip Hanik - Dev Lists wrote:
>>>>>
>>>>>
>>>>>> Remy Maucherat wrote:
>>>>>>
>>>>>>
>>>>>>> Hi,
>>>>>>>
>>>>>>> Another more precise draft.
>>>>>>>
>>>>>>> Patches which would go to review would be:
>>>>>>> - API changing patches (any protected or above signature change) on
>>>>>>> APIs which are accessible to the user either from confirguration or
>>>>>>> programmatically
>>>>>>>
>>>>>>>
>>>>>> yes, makes sense
>>>>>>
>>>>>>
>>>>>>> - any other commit for which a committer asks for the RTC procedure
>>>>>>> should be rollbacked if it hinders concurrent work or is to be
>>>>>>> included in a release tag, and go through the RTC procedure
>>>>>>>
>>>>>>>
>>>>>> -1. There is a huge risk for "I simply don't like it, revert it".
>>>>>> Anything that is to be rolled back, should be backed up by a technical
>>>>>> reason. So in this case, how do you define "it hinders concurrent
>>>>>> work".
>>>>>> Either we do RTC or we don't, but having a vague definition in
>>>>>> between,
>>>>>> doesn't make sense.
>>>>>>
>>>>>>
>>>>> That is not: "I simply don't like it, revert it" that is "I think it
>>>>> needs review, revert it and let's discuss it".
>>>>> I would proposed that the one that does the -1 should come with another
>>>>> fix in few days for a fix for a PR, another proposal for API/conf
>>>>> changes and participate to the discussion on the -1 otherwise the -1
>>>>> would become is invalid.
>>>>>
>>>>>
>>>> The patch does not need to be reverted when under review, except if
>>>> there's a need to tag a release or something similar.
>>>>
>>>>
>>> Well I see at least 3 reasons to revert it:
>>> - Prevent accidental inclusion in a release.
>>> - Allow a more easy testing and evaluation of a another patch that fixes
>>> the same thing.
>>> - Force the community to look for another solution.
>>>
>>>
>> so to me this is spanking clear, that the process is vague, and before
>> anything like this is implemented, it should be as black and white as RTC
>> and CTR if it's gonna work
>> at this point, the vote doesn't make sense, as it is obvious folks aren't
>> clear on the process being voted on.
>>
>>
>
> And, yet again, Filip chooses to question the validity of the vote, instead
> of discussing ideas :(. Now I feel insulted as well, since I'm fully aware
> on the process being voted on. But if I lived with Jon in the same
> community, I can live with Filip ;-).
>
how can we vote, if the thread goes into discussion. The ASF clearly has
to methods of developing, CTR or RTC,
So there are two questions here
1. Why do we need something in between
2. This is the third time around this topic has been discussed, and
folks are still unclear on the process or the desire thereof, you might
be clear, but me, and others based on the thread for sure aren't. The
new model is not black and white, but it would have to be in order to work.
I'd say, stick to what we know, the ASF ways. And Bill, thanks for
comparing me to Jon. If you ever show up at an ApacheCon, the first beer
will be on me :)
> Remy was being really nice to the community by not requiring a vetoed patch
> to be withdrawn. Personally, I would go with j-f-c's position, and withdraw
> a vetoed patch immediately (and have done so on several occations, even when
> I got to re-apply it after enough discussion took place on the list).
> However, I'll go with whatever the community consensus is on this point.
>
Yes, and I too appreciate the effort, although, I do think it's better
to stick with the ASF ways, so that there is no question on how things
should be done.
If you want development in a non ASF way, there are plenty of other
places to do development than the ASF
Filip
>
>> Filip
>>
>>> Cheers
>>>
>>> Jean-Frederic
>>>
>>>
>>>
>>>> In that case,
>>>> including such a patch would not be acceptable. The other case is if it
>>>> causes development issues, but it should be extremely rare (as API
>>>> changing patches would get reviewed before being committed).
>>>>
>>>> I also don't think any reason needs to be given for voting against a
>>>> particular patch under review. If only one committer votes "no", then
>>>> you need one additional "yes" (4 total), which sounds achievable. If two
>>>> committers vote "no" (most likely you would be in a veto situation at
>>>> the moment) then it's still doable if everybody else wants it. With 3
>>>> against, the community is basically split, and it seems impossible to
>>>> follow through without changes to convince the other camp.
>>>>
>>>> The general idea is to be able to disagree with something without using
>>>> something absolute like the veto mechanism, since the only thing that is
>>>> going to be examined (at least at the moment) seems to be its validity.
>>>> Also, if a vote is tied to a justification, then any discussions will
>>>> immediately switch over from technical to "let's show the justification
>>>> is not valid, so that we can ignore it" mode.
>>>>
>>>> If it turns this new mechanism does not work, then I think new proposals
>>>> can be made to change it quite easily.
>>>>
>>>> Rémy
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
>>>> For additional commands, e-mail: dev-help@tomcat.apache.org
>>>>
>>>>
>>>>
>>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
>>> For additional commands, e-mail: dev-help@tomcat.apache.org
>>>
>>>
>>>
>>>
>>>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Review model take 2
Posted by Bill Barker <wb...@wilshire.com>.
"Filip Hanik - Dev Lists" <de...@hanik.com> wrote in message
news:46F12965.2080404@hanik.com...
> jean-frederic clere wrote:
>> Remy Maucherat wrote:
>>
>>> jean-frederic clere wrote:
>>>
>>>> Filip Hanik - Dev Lists wrote:
>>>>
>>>>> Remy Maucherat wrote:
>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> Another more precise draft.
>>>>>>
>>>>>> Patches which would go to review would be:
>>>>>> - API changing patches (any protected or above signature change) on
>>>>>> APIs which are accessible to the user either from confirguration or
>>>>>> programmatically
>>>>>>
>>>>> yes, makes sense
>>>>>
>>>>>> - any other commit for which a committer asks for the RTC procedure
>>>>>> should be rollbacked if it hinders concurrent work or is to be
>>>>>> included in a release tag, and go through the RTC procedure
>>>>>>
>>>>> -1. There is a huge risk for "I simply don't like it, revert it".
>>>>> Anything that is to be rolled back, should be backed up by a technical
>>>>> reason. So in this case, how do you define "it hinders concurrent
>>>>> work".
>>>>> Either we do RTC or we don't, but having a vague definition in
>>>>> between,
>>>>> doesn't make sense.
>>>>>
>>>> That is not: "I simply don't like it, revert it" that is "I think it
>>>> needs review, revert it and let's discuss it".
>>>> I would proposed that the one that does the -1 should come with another
>>>> fix in few days for a fix for a PR, another proposal for API/conf
>>>> changes and participate to the discussion on the -1 otherwise the -1
>>>> would become is invalid.
>>>>
>>> The patch does not need to be reverted when under review, except if
>>> there's a need to tag a release or something similar.
>>>
>>
>> Well I see at least 3 reasons to revert it:
>> - Prevent accidental inclusion in a release.
>> - Allow a more easy testing and evaluation of a another patch that fixes
>> the same thing.
>> - Force the community to look for another solution.
>>
>
> so to me this is spanking clear, that the process is vague, and before
> anything like this is implemented, it should be as black and white as RTC
> and CTR if it's gonna work
> at this point, the vote doesn't make sense, as it is obvious folks aren't
> clear on the process being voted on.
>
And, yet again, Filip chooses to question the validity of the vote, instead
of discussing ideas :(. Now I feel insulted as well, since I'm fully aware
on the process being voted on. But if I lived with Jon in the same
community, I can live with Filip ;-).
Remy was being really nice to the community by not requiring a vetoed patch
to be withdrawn. Personally, I would go with j-f-c's position, and withdraw
a vetoed patch immediately (and have done so on several occations, even when
I got to re-apply it after enough discussion took place on the list).
However, I'll go with whatever the community consensus is on this point.
> Filip
>> Cheers
>>
>> Jean-Frederic
>>
>>
>>> In that case,
>>> including such a patch would not be acceptable. The other case is if it
>>> causes development issues, but it should be extremely rare (as API
>>> changing patches would get reviewed before being committed).
>>>
>>> I also don't think any reason needs to be given for voting against a
>>> particular patch under review. If only one committer votes "no", then
>>> you need one additional "yes" (4 total), which sounds achievable. If two
>>> committers vote "no" (most likely you would be in a veto situation at
>>> the moment) then it's still doable if everybody else wants it. With 3
>>> against, the community is basically split, and it seems impossible to
>>> follow through without changes to convince the other camp.
>>>
>>> The general idea is to be able to disagree with something without using
>>> something absolute like the veto mechanism, since the only thing that is
>>> going to be examined (at least at the moment) seems to be its validity.
>>> Also, if a vote is tied to a justification, then any discussions will
>>> immediately switch over from technical to "let's show the justification
>>> is not valid, so that we can ignore it" mode.
>>>
>>> If it turns this new mechanism does not work, then I think new proposals
>>> can be made to change it quite easily.
>>>
>>> R�my
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
>>> For additional commands, e-mail: dev-help@tomcat.apache.org
>>>
>>>
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: dev-help@tomcat.apache.org
>>
>>
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Review model take 2
Posted by Filip Hanik - Dev Lists <de...@hanik.com>.
jean-frederic clere wrote:
> Remy Maucherat wrote:
>
>> jean-frederic clere wrote:
>>
>>> Filip Hanik - Dev Lists wrote:
>>>
>>>> Remy Maucherat wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> Another more precise draft.
>>>>>
>>>>> Patches which would go to review would be:
>>>>> - API changing patches (any protected or above signature change) on
>>>>> APIs which are accessible to the user either from confirguration or
>>>>> programmatically
>>>>>
>>>> yes, makes sense
>>>>
>>>>> - any other commit for which a committer asks for the RTC procedure
>>>>> should be rollbacked if it hinders concurrent work or is to be
>>>>> included in a release tag, and go through the RTC procedure
>>>>>
>>>> -1. There is a huge risk for "I simply don't like it, revert it".
>>>> Anything that is to be rolled back, should be backed up by a technical
>>>> reason. So in this case, how do you define "it hinders concurrent work".
>>>> Either we do RTC or we don't, but having a vague definition in between,
>>>> doesn't make sense.
>>>>
>>> That is not: "I simply don't like it, revert it" that is "I think it
>>> needs review, revert it and let's discuss it".
>>> I would proposed that the one that does the -1 should come with another
>>> fix in few days for a fix for a PR, another proposal for API/conf
>>> changes and participate to the discussion on the -1 otherwise the -1
>>> would become is invalid.
>>>
>> The patch does not need to be reverted when under review, except if
>> there's a need to tag a release or something similar.
>>
>
> Well I see at least 3 reasons to revert it:
> - Prevent accidental inclusion in a release.
> - Allow a more easy testing and evaluation of a another patch that fixes
> the same thing.
> - Force the community to look for another solution.
>
so to me this is spanking clear, that the process is vague, and before
anything like this is implemented, it should be as black and white as
RTC and CTR if it's gonna work
at this point, the vote doesn't make sense, as it is obvious folks
aren't clear on the process being voted on.
Filip
> Cheers
>
> Jean-Frederic
>
>
>> In that case,
>> including such a patch would not be acceptable. The other case is if it
>> causes development issues, but it should be extremely rare (as API
>> changing patches would get reviewed before being committed).
>>
>> I also don't think any reason needs to be given for voting against a
>> particular patch under review. If only one committer votes "no", then
>> you need one additional "yes" (4 total), which sounds achievable. If two
>> committers vote "no" (most likely you would be in a veto situation at
>> the moment) then it's still doable if everybody else wants it. With 3
>> against, the community is basically split, and it seems impossible to
>> follow through without changes to convince the other camp.
>>
>> The general idea is to be able to disagree with something without using
>> something absolute like the veto mechanism, since the only thing that is
>> going to be examined (at least at the moment) seems to be its validity.
>> Also, if a vote is tied to a justification, then any discussions will
>> immediately switch over from technical to "let's show the justification
>> is not valid, so that we can ignore it" mode.
>>
>> If it turns this new mechanism does not work, then I think new proposals
>> can be made to change it quite easily.
>>
>> Rémy
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: dev-help@tomcat.apache.org
>>
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Review model take 2
Posted by jean-frederic clere <jf...@gmail.com>.
Remy Maucherat wrote:
> jean-frederic clere wrote:
>> Filip Hanik - Dev Lists wrote:
>>> Remy Maucherat wrote:
>>>> Hi,
>>>>
>>>> Another more precise draft.
>>>>
>>>> Patches which would go to review would be:
>>>> - API changing patches (any protected or above signature change) on
>>>> APIs which are accessible to the user either from confirguration or
>>>> programmatically
>>> yes, makes sense
>>>> - any other commit for which a committer asks for the RTC procedure
>>>> should be rollbacked if it hinders concurrent work or is to be
>>>> included in a release tag, and go through the RTC procedure
>>> -1. There is a huge risk for "I simply don't like it, revert it".
>>> Anything that is to be rolled back, should be backed up by a technical
>>> reason. So in this case, how do you define "it hinders concurrent work".
>>> Either we do RTC or we don't, but having a vague definition in between,
>>> doesn't make sense.
>>
>> That is not: "I simply don't like it, revert it" that is "I think it
>> needs review, revert it and let's discuss it".
>> I would proposed that the one that does the -1 should come with another
>> fix in few days for a fix for a PR, another proposal for API/conf
>> changes and participate to the discussion on the -1 otherwise the -1
>> would become is invalid.
>
> The patch does not need to be reverted when under review, except if
> there's a need to tag a release or something similar.
Well I see at least 3 reasons to revert it:
- Prevent accidental inclusion in a release.
- Allow a more easy testing and evaluation of a another patch that fixes
the same thing.
- Force the community to look for another solution.
Cheers
Jean-Frederic
> In that case,
> including such a patch would not be acceptable. The other case is if it
> causes development issues, but it should be extremely rare (as API
> changing patches would get reviewed before being committed).
>
> I also don't think any reason needs to be given for voting against a
> particular patch under review. If only one committer votes "no", then
> you need one additional "yes" (4 total), which sounds achievable. If two
> committers vote "no" (most likely you would be in a veto situation at
> the moment) then it's still doable if everybody else wants it. With 3
> against, the community is basically split, and it seems impossible to
> follow through without changes to convince the other camp.
>
> The general idea is to be able to disagree with something without using
> something absolute like the veto mechanism, since the only thing that is
> going to be examined (at least at the moment) seems to be its validity.
> Also, if a vote is tied to a justification, then any discussions will
> immediately switch over from technical to "let's show the justification
> is not valid, so that we can ignore it" mode.
>
> If it turns this new mechanism does not work, then I think new proposals
> can be made to change it quite easily.
>
> Rémy
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Review model take 2
Posted by Remy Maucherat <re...@apache.org>.
jean-frederic clere wrote:
> Filip Hanik - Dev Lists wrote:
>> Remy Maucherat wrote:
>>> Hi,
>>>
>>> Another more precise draft.
>>>
>>> Patches which would go to review would be:
>>> - API changing patches (any protected or above signature change) on
>>> APIs which are accessible to the user either from confirguration or
>>> programmatically
>> yes, makes sense
>>> - any other commit for which a committer asks for the RTC procedure
>>> should be rollbacked if it hinders concurrent work or is to be
>>> included in a release tag, and go through the RTC procedure
>> -1. There is a huge risk for "I simply don't like it, revert it".
>> Anything that is to be rolled back, should be backed up by a technical
>> reason. So in this case, how do you define "it hinders concurrent work".
>> Either we do RTC or we don't, but having a vague definition in between,
>> doesn't make sense.
>
> That is not: "I simply don't like it, revert it" that is "I think it
> needs review, revert it and let's discuss it".
> I would proposed that the one that does the -1 should come with another
> fix in few days for a fix for a PR, another proposal for API/conf
> changes and participate to the discussion on the -1 otherwise the -1
> would become is invalid.
The patch does not need to be reverted when under review, except if
there's a need to tag a release or something similar. In that case,
including such a patch would not be acceptable. The other case is if it
causes development issues, but it should be extremely rare (as API
changing patches would get reviewed before being committed).
I also don't think any reason needs to be given for voting against a
particular patch under review. If only one committer votes "no", then
you need one additional "yes" (4 total), which sounds achievable. If two
committers vote "no" (most likely you would be in a veto situation at
the moment) then it's still doable if everybody else wants it. With 3
against, the community is basically split, and it seems impossible to
follow through without changes to convince the other camp.
The general idea is to be able to disagree with something without using
something absolute like the veto mechanism, since the only thing that is
going to be examined (at least at the moment) seems to be its validity.
Also, if a vote is tied to a justification, then any discussions will
immediately switch over from technical to "let's show the justification
is not valid, so that we can ignore it" mode.
If it turns this new mechanism does not work, then I think new proposals
can be made to change it quite easily.
Rémy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Review model take 2
Posted by jean-frederic clere <jf...@gmail.com>.
Filip Hanik - Dev Lists wrote:
> Remy Maucherat wrote:
>> Hi,
>>
>> Another more precise draft.
>>
>> Patches which would go to review would be:
>> - API changing patches (any protected or above signature change) on
>> APIs which are accessible to the user either from confirguration or
>> programmatically
> yes, makes sense
>> - any other commit for which a committer asks for the RTC procedure
>> should be rollbacked if it hinders concurrent work or is to be
>> included in a release tag, and go through the RTC procedure
> -1. There is a huge risk for "I simply don't like it, revert it".
> Anything that is to be rolled back, should be backed up by a technical
> reason. So in this case, how do you define "it hinders concurrent work".
> Either we do RTC or we don't, but having a vague definition in between,
> doesn't make sense.
That is not: "I simply don't like it, revert it" that is "I think it
needs review, revert it and let's discuss it".
I would proposed that the one that does the -1 should come with another
fix in few days for a fix for a PR, another proposal for API/conf
changes and participate to the discussion on the -1 otherwise the -1
would become is invalid.
>>
>> The RTC procedure would include a STATUS file in the Tomcat svn
>> listing all pending "up to review" changes. A successful vote with a
>> +3 margin is required. A patch can remain under review for as long as
>> the committer wishes, and it should be allowed to freely "advertise"
>> and discuss the vote.
>>
>> The idea would be to force a consensus for commits which could have
>> significant implications, and help stage technical discussions (rather
>> than discussions about the validity of the disagreement). It would
>> introduce a small delay for committing certain patches and a minor
>> slowdown for development pace in theory, but in practice I've noticed
>> conflicts waste a lot more time.
> The community has always been open to technical discussions, it's the
> countless vetoes without technical justifications that became the major
> pain in the rear.
The problem is more the time that is spend to discuss the validity of -1
is lost time for me. It seems a reaction to a veto of a commit in the TC
community is somehow wrong... The correct way should be "thank you for
reviewing my commit, I will rollback and let's discuss a better
solution" and not what happens those days.
>>
>> This would also mean it is possible to make a change that a number of
>> committers oppose (possibly, would veto) if enough committers are in
>> favor of it.
> I don't really see the need of doing our own version of a semi RTC,
> either we do RTC on release branches and CTR on trunk.
> So I'd be -1 on this, the main reason, is that the definitions are not
> common nor defined within the larger ASF community, hence the vagueness
> would only arise for more debates.
What Remy proposed is a RTC on demand I think we should try it and
improve it while using it.
Cheers
Jean-Frederic
>
> Filip
>>
>> Rémy
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: dev-help@tomcat.apache.org
>>
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Review model take 2
Posted by Filip Hanik - Dev Lists <de...@hanik.com>.
Remy Maucherat wrote:
> Hi,
>
> Another more precise draft.
>
> Patches which would go to review would be:
> - API changing patches (any protected or above signature change) on
> APIs which are accessible to the user either from confirguration or
> programmatically
yes, makes sense
> - any other commit for which a committer asks for the RTC procedure
> should be rollbacked if it hinders concurrent work or is to be
> included in a release tag, and go through the RTC procedure
-1. There is a huge risk for "I simply don't like it, revert it".
Anything that is to be rolled back, should be backed up by a technical
reason. So in this case, how do you define "it hinders concurrent work".
Either we do RTC or we don't, but having a vague definition in between,
doesn't make sense.
>
> The RTC procedure would include a STATUS file in the Tomcat svn
> listing all pending "up to review" changes. A successful vote with a
> +3 margin is required. A patch can remain under review for as long as
> the committer wishes, and it should be allowed to freely "advertise"
> and discuss the vote.
>
> The idea would be to force a consensus for commits which could have
> significant implications, and help stage technical discussions (rather
> than discussions about the validity of the disagreement). It would
> introduce a small delay for committing certain patches and a minor
> slowdown for development pace in theory, but in practice I've noticed
> conflicts waste a lot more time.
The community has always been open to technical discussions, it's the
countless vetoes without technical justifications that became the major
pain in the rear.
>
> This would also mean it is possible to make a change that a number of
> committers oppose (possibly, would veto) if enough committers are in
> favor of it.
I don't really see the need of doing our own version of a semi RTC,
either we do RTC on release branches and CTR on trunk.
So I'd be -1 on this, the main reason, is that the definitions are not
common nor defined within the larger ASF community, hence the vagueness
would only arise for more debates.
Filip
>
> Rémy
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Review model take 2
Posted by Bill Barker <wb...@wilshire.com>.
+1
I agree with Costin here. If it can't be added/removed as a pluggin, then
it doesn't belong in the default Tomcat distro.
"Costin Manolache" <co...@gmail.com> wrote in message
news:96e4b5230709181502w6610e261h124dd45631fa33f0@mail.gmail.com...
> +1
>
> I think one exception ( or maybe something that should be easily
> fast-tracked ):
> - adding new hooks to allow such features to be developed and plugged in
> as
> separate modules
>
> For any new feature or bigger change to a component that already has a
> plugin mechanism ( connector, etc ) -
> it would be better to have it developed as an optional module ( i.e. not
> included in the default build, but
> as a separate jar that can be easily installed in lib/ ), and after it
> gets
> released, tested, etc - it could
> be moved to the official distro based on a similar vote.
>
> That would mean that any 'itch scratching', new feature or major change
> can
> still be done in CTR mode,
> in the main branch (instead of sandbox), and be usable.
>
> Costin
>
> On 9/18/07, Remy Maucherat <re...@apache.org> wrote:
>>
>> Hi,
>>
>> Another more precise draft.
>>
>> Patches which would go to review would be:
>> - API changing patches (any protected or above signature change) on APIs
>> which are accessible to the user either from confirguration or
>> programmatically
>> - any other commit for which a committer asks for the RTC procedure
>> should be rollbacked if it hinders concurrent work or is to be included
>> in a release tag, and go through the RTC procedure
>>
>> The RTC procedure would include a STATUS file in the Tomcat svn listing
>> all pending "up to review" changes. A successful vote with a +3 margin
>> is required. A patch can remain under review for as long as the
>> committer wishes, and it should be allowed to freely "advertise" and
>> discuss the vote.
>>
>> The idea would be to force a consensus for commits which could have
>> significant implications, and help stage technical discussions (rather
>> than discussions about the validity of the disagreement). It would
>> introduce a small delay for committing certain patches and a minor
>> slowdown for development pace in theory, but in practice I've noticed
>> conflicts waste a lot more time.
>>
>> This would also mean it is possible to make a change that a number of
>> committers oppose (possibly, would veto) if enough committers are in
>> favor of it.
>>
>> R�my
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: dev-help@tomcat.apache.org
>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Review model take 2
Posted by Costin Manolache <co...@gmail.com>.
+1
I think one exception ( or maybe something that should be easily
fast-tracked ):
- adding new hooks to allow such features to be developed and plugged in as
separate modules
For any new feature or bigger change to a component that already has a
plugin mechanism ( connector, etc ) -
it would be better to have it developed as an optional module ( i.e. not
included in the default build, but
as a separate jar that can be easily installed in lib/ ), and after it gets
released, tested, etc - it could
be moved to the official distro based on a similar vote.
That would mean that any 'itch scratching', new feature or major change can
still be done in CTR mode,
in the main branch (instead of sandbox), and be usable.
Costin
On 9/18/07, Remy Maucherat <re...@apache.org> wrote:
>
> Hi,
>
> Another more precise draft.
>
> Patches which would go to review would be:
> - API changing patches (any protected or above signature change) on APIs
> which are accessible to the user either from confirguration or
> programmatically
> - any other commit for which a committer asks for the RTC procedure
> should be rollbacked if it hinders concurrent work or is to be included
> in a release tag, and go through the RTC procedure
>
> The RTC procedure would include a STATUS file in the Tomcat svn listing
> all pending "up to review" changes. A successful vote with a +3 margin
> is required. A patch can remain under review for as long as the
> committer wishes, and it should be allowed to freely "advertise" and
> discuss the vote.
>
> The idea would be to force a consensus for commits which could have
> significant implications, and help stage technical discussions (rather
> than discussions about the validity of the disagreement). It would
> introduce a small delay for committing certain patches and a minor
> slowdown for development pace in theory, but in practice I've noticed
> conflicts waste a lot more time.
>
> This would also mean it is possible to make a change that a number of
> committers oppose (possibly, would veto) if enough committers are in
> favor of it.
>
> Rémy
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
>