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,
[ ] +1. Yes, the above works and addresses my concerns
as well as the problems which started this whole
thing.
Just to be sure
2007/9/26, Jim Jagielski [EMAIL PROTECTED]:
I'd like to call a vote on acceptance of the above methodology,
as crafted and fine-tuned by
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
+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
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:
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
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
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:
[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
+1
2007/9/23, Peter Rossbach [EMAIL PROTECTED]:
[X] +1. Yes, the above works and addresses my concerns
as well as the problems which started this whole
thing.
[ ] 0. Whatever.
[ ] -1. The above does not work for the following reasons:
I agree with Remy:
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
On Sep 21, 2007, at 4:36 PM, Jim Jagielski wrote:
On Sep 21, 2007, at 4:27 PM, Costin Manolache wrote:
On 9/21/07, Jim Jagielski [EMAIL PROTECTED] wrote:
Just propose a polite way to move from the commit for a
controversial
change ( i.e. when someone feels strongly it's going to the
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
Hey,
On 9/22/07, Jim Jagielski [EMAIL PROTECTED] wrote:
[ X ] +1. Yes, the above works and addresses my concerns
as well as the problems which started this whole
thing.
Yoav
-
To unsubscribe,
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
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
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:
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:
this email is so unclean, I'm a bit confused on the exact bullets, mind
posting a new thread?
Filip
Jim Jagielski wrote:
On Sep 21, 2007, at 4:36 PM, Jim Jagielski wrote:
On Sep 21, 2007, at 4:27 PM, Costin Manolache wrote:
On 9/21/07, Jim Jagielski [EMAIL PROTECTED] wrote:
Just
+1
On 9/22/07, Jim Jagielski [EMAIL PROTECTED] wrote:
On Sep 22, 2007, at 9:45 AM, Jim Jagielski wrote:
[X] +1. Yes, the above works and addresses my concerns
as well as the problems which started this whole
thing.
[ ] 0. Whatever.
[ ] -1. The above
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
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
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
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
So what about RTC for core and CTR for extensions in incubator land ?
2007/9/21, Costin Manolache [EMAIL PROTECTED]:
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
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
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
+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 [EMAIL PROTECTED]:
Filip Hanik - Dev Lists wrote:
It could be a simple as (as opposed to trying to reinvent the apache way)
1. Through out a
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,
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...
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
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
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
On 9/21/07, Jim Jagielski [EMAIL PROTECTED] 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
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
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
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
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
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?
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
On 9/21/07, Jim Jagielski [EMAIL PROTECTED] 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
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
On 9/21/07, Jim Jagielski [EMAIL PROTECTED] 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
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
On 9/21/07, Jim Jagielski [EMAIL PROTECTED] wrote:
Just propose a polite way to move from the commit for a controversial
change ( i.e. when someone feels strongly it's going to the wrong
direction,
even
if technically code is ok ) to the majority and 3+1 process - and
we're
done.
On Sep 21, 2007, at 4:27 PM, Costin Manolache wrote:
On 9/21/07, Jim Jagielski [EMAIL PROTECTED] wrote:
Just propose a polite way to move from the commit for a
controversial
change ( i.e. when someone feels strongly it's going to the wrong
direction,
even
if technically code is ok ) to
William A. Rowe, Jr. [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
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
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
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
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
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
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
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
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
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)
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
On 9/20/07, Jim Jagielski [EMAIL PROTECTED] 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
Bill Barker wrote:
Filip Hanik - Dev Lists [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
jean-frederic clere wrote:
Remy Maucherat wrote:
jean-frederic clere wrote:
Filip Hanik - Dev Lists wrote:
Remy Maucherat wrote:
Hi,
Costin Manolache wrote:
On 9/20/07, Jim Jagielski [EMAIL PROTECTED] 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
Filip Hanik - Dev Lists wrote:
Bill Barker wrote:
Filip Hanik - Dev Lists [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
jean-frederic clere wrote:
Remy Maucherat wrote:
jean-frederic clere wrote:
Filip Hanik - Dev Lists wrote:
Remy
Filip Hanik - Dev Lists wrote:
Costin Manolache wrote:
On 9/20/07, Jim Jagielski [EMAIL PROTECTED] 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
On 9/20/07, Filip Hanik - Dev Lists [EMAIL PROTECTED] 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
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
On Sep 20, 2007, at 9:57 AM, Costin Manolache wrote:
On 9/20/07, Jim Jagielski [EMAIL PROTECTED] 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
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.
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.
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
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 [EMAIL PROTECTED] (it's bad form to crosspost a message
with both public-and-private destinations).
Bill Barker wrote:
William
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
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
+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
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,
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
+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 [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
+1
I think one exception ( or maybe something that should be easily
fast-tracked ):
-
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
+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
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
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
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
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
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
Filip Hanik - Dev Lists [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
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
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
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
William A. Rowe, Jr. [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
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
Hey,
On 9/18/07, Remy Maucherat [EMAIL PROTECTED] 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
+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
+1
-Tim
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
88 matches
Mail list logo
