Jim Jagielski wrote:
On Sep 10, 2007, at 8:00 PM, Mark Thomas wrote:
Jim Jagielski wrote:
How about:
o CTR on trunk
o Various release branches are made (ala httpd, apr, etc...).
These include a STATUS file.
o All code applied to the release branch is under
lazy
Mark Thomas wrote:
On Sep 10, 2007, at 4:47 PM, Remy Maucherat wrote:
The main idea is that since there's only one trunk branch, there
should be agreement on APIs and important topics to proceed
++1. So let's start that now. Since there is not agreement on APIs,
how do we proceed
Filip Hanik - Dev Lists wrote:
Mark Thomas wrote:
On Sep 10, 2007, at 4:47 PM, Remy Maucherat wrote:
The main idea is that since there's only one trunk branch, there
should be agreement on APIs and important topics to proceed
++1. So let's start that now. Since there is not
Mark Thomas wrote:
Filip Hanik - Dev Lists wrote:
Mark Thomas wrote:
On Sep 10, 2007, at 4:47 PM, Remy Maucherat wrote:
The main idea is that since there's only one trunk branch, there
should be agreement on APIs and important topics to proceed
++1.
On Sep 10, 2007, at 8:00 PM, Mark Thomas wrote:
Jim Jagielski wrote:
How about:
o CTR on trunk
o Various release branches are made (ala httpd, apr, etc...).
These include a STATUS file.
o All code applied to the release branch is under
lazy consensus but *must* be
On Sep 10, 2007, at 4:47 PM, Remy Maucherat wrote:
The main idea is that since there's only one trunk branch, there
should be agreement on APIs and important topics to proceed
++1. So let's start that now. Since there is not agreement on APIs,
how do we proceed from here? Or, in other
Jim Jagielski wrote:
I have no idea how you could possibly justify that statement.
With RTC one *requires* 3 +1 votes. The above does not.
And STATUS is there to indicate what *will* be done, not
what *has* been done.
It's usually a good idea to actually read and understand
posts before
Jim Jagielski wrote:
On Sep 10, 2007, at 4:47 PM, Remy Maucherat wrote:
The main idea is that since there's only one trunk branch, there
should be agreement on APIs and important topics to proceed
++1. So let's start that now. Since there is not agreement on APIs,
how do we proceed from
Mladen Turk wrote:
Remy Maucherat wrote:
To give an idea, tis could mean:
- API changing patches (any protected or above signature change)
- code changes in the critical path (for example, code which gets
executed on each HTTP request)
Fine.
- any other commit for which a committer asks
How about:
o CTR on trunk
o Various release branches are made (ala httpd, apr, etc...).
These include a STATUS file.
o All code applied to the release branch is under
lazy consensus but *must* be specified in STATUS.
(eg: I plan on applying rev786987 in 3 days under
Remy Maucherat wrote:
Mladen Turk wrote:
Remy Maucherat wrote:
To give an idea, tis could mean:
- API changing patches (any protected or above signature change)
- code changes in the critical path (for example, code which gets
executed on each HTTP request)
Fine.
- any
Jim Jagielski wrote:
How about:
o CTR on trunk
o Various release branches are made (ala httpd, apr, etc...).
These include a STATUS file.
o All code applied to the release branch is under
lazy consensus but *must* be specified in STATUS.
(eg: I plan on applying
Hey,
On 9/10/07, Jim Jagielski [EMAIL PROTECTED] wrote:
How about:
o CTR on trunk
o Various release branches are made (ala httpd, apr, etc...).
These include a STATUS file.
o All code applied to the release branch is under
lazy consensus but *must* be specified in
Jim Jagielski wrote:
How about:
o CTR on trunk
o Various release branches are made (ala httpd, apr, etc...).
These include a STATUS file.
o All code applied to the release branch is under
lazy consensus but *must* be specified in STATUS.
(eg: I plan on applying
Jim Jagielski wrote:
How about:
o CTR on trunk
o Various release branches are made (ala httpd, apr, etc...).
These include a STATUS file.
o All code applied to the release branch is under
lazy consensus but *must* be specified in STATUS.
(eg: I plan on applying
On Sep 6, 2007, at 1:22 PM, Remy Maucherat wrote:
Most of the comments were that it was too annoying to do for casual
bugfixing, and it's true it's not justified for all patches. Maybe
a finer rule could be devised, something like using a RtisTC (tis =
the important stuff) model.
To
bottom line is that
1. moving trunk to sandbox
2. trying to implement a semi RTC
both do nothing but hurt Tomcat moving forward, and falling further
behind in the servlet container space.
The whole debate that has risen up, is only based on conjured up
supposed breakage of the CTR model
2007/9/6, Mladen Turk [EMAIL PROTECTED]:
Henri Gomez wrote:
Well what's the consensus on Java projects, like Xerces, Xalan or Lucene ?
It doesn't mater how other project do things. It's irrelevant.
Well all projects are ASF projects and it's not bad to see what others
do, just to avoid the
Remy Maucherat wrote:
Filip Hanik - Dev Lists wrote:
I get more and more provocations from you, for example on the
Servlet expert group, where you could not resist alluding to this
conflict in your introduction.
huh? it was a mere reference that we are working on the same project,
twist it
Filip Hanik - Dev Lists wrote:
you start to sound like you believe yourself by this point.
After my vacation, I'll pull out the emails you wrote, where, even
though it was a veto, you clearly specified to leave it in.
I will also pull out the email, where I offered to elaborate more, and
you
Remy Maucherat wrote:
Filip Hanik - Dev Lists wrote:
you start to sound like you believe yourself by this point.
After my vacation, I'll pull out the emails you wrote, where, even
though it was a veto, you clearly specified to leave it in.
I will also pull out the email, where I offered to
Henri Gomez wrote:
Well what's the consensus on Java projects, like Xerces, Xalan or Lucene ?
It doesn't mater how other project do things. It's irrelevant.
We had CTR policy till now and it was working.
Now we have a new situation with different developers POVs,
and cause of that, this
Filip Hanik - Dev Lists wrote:
I get more and more provocations from you, for example on the Servlet
expert group, where you could not resist alluding to this conflict in
your introduction.
huh? it was a mere reference that we are working on the same project,
twist it anyway you want.
Ok. It
Hi,
On 9/6/07, Mladen Turk [EMAIL PROTECTED] wrote:
It doesn't mater how other project do things. It's irrelevant.
I agree with that.
We had CTR policy till now and it was working.
It's still working. We've already voted to move the current trunk
into a special sandbox, with no loss of
Mladen Turk wrote:
Henri Gomez wrote:
Well what's the consensus on Java projects, like Xerces, Xalan or
Lucene ?
It doesn't mater how other project do things. It's irrelevant.
We had CTR policy till now and it was working.
Now we have a new situation with different developers POVs,
and cause
Hey,
On 9/6/07, Remy Maucherat [EMAIL PROTECTED] wrote:
Most of the comments were that it was too annoying to do for casual
bugfixing, and it's true it's not justified for all patches. Maybe a
finer rule could be devised, something like using a RtisTC (tis = the
important stuff) model.
To
Yoav Shapira wrote:
Hi,
On 9/6/07, Mladen Turk [EMAIL PROTECTED] wrote:
Do we need it? Yes, if we wish to survive as a project.
It's pain in the ass, I know, but IMHO it's also the only
way to get some sense in this chaos.
I disagree. I think the current CTR policy has worked just fine and
Remy Maucherat wrote:
To give an idea, tis could mean:
- API changing patches (any protected or above signature change)
- code changes in the critical path (for example, code which gets
executed on each HTTP request)
Fine.
- any other commit for which a committer asks for the RTC procedure
Filip Hanik - Dev Lists wrote:
yes, it is also easily abused by folks who throw around vetoes as often
as I change underwear.
Ouch, that must smell.
I don't see a need to slow down development even
further, at this point if the previous vote is considered valid, we
don't even have a
On Sep 5, 2007, at 5:51 AM, Remy Maucherat wrote:
Filip Hanik - Dev Lists wrote:
yes, it is also easily abused by folks who throw around vetoes as
often as I change underwear.
Ouch, that must smell.
I don't see a need to slow down development even further, at this
point if the previous
Jim Jagielski wrote:
On Sep 5, 2007, at 5:51 AM, Remy Maucherat wrote:
Filip Hanik - Dev Lists wrote:
yes, it is also easily abused by folks who throw around vetoes as
often as I change underwear.
Ouch, that must smell.
I don't see a need to slow down development even further, at this
Remy Maucherat wrote:
Jim Jagielski wrote:
On Sep 5, 2007, at 5:51 AM, Remy Maucherat wrote:
Filip Hanik - Dev Lists wrote:
yes, it is also easily abused by folks who throw around vetoes as
often as I change underwear.
Ouch, that must smell.
I don't see a need to slow down development
Hi,
I would also propose that we take an handling of release branches
similar to httpd.
The release branches are:
/tomcat/tc6.0.x/trunk
/tomcat/build/tc5.5.x/
/tomcat/container/tc5.5.x
/tomcat/jasper/tc5.5.x/
(Note it uses /tomcat/connectors/trunk)
/tomcat/build/branches/tc5.0.x
Hey,
On 9/4/07, jean-frederic clere [EMAIL PROTECTED] wrote:
I would also propose that we take an handling of release branches
similar to httpd.
snip /
The votes will get in a file named STATUS file and once accepted in a
file named CHANGES.
The proposal of backports/fixes should be a
What is a change? Any commit?
Is a change only for new features and bug fixes are out of scope?
-Tim
jean-frederic clere wrote:
Hi,
I would also propose that we take an handling of release branches
similar to httpd.
The votes will get in a file named STATUS file and once accepted in a
file
jean-frederic clere wrote:
Hi,
I would also propose that we take an handling of release branches
similar to httpd.
The release branches are:
/tomcat/tc6.0.x/trunk
/tomcat/build/tc5.5.x/
/tomcat/container/tc5.5.x
/tomcat/jasper/tc5.5.x/
(Note it uses /tomcat/connectors/trunk)
jean-frederic clere wrote:
The votes will get in a file named STATUS file and once accepted in a
file named CHANGES.
The proposal of backports/fixes should be a description of the
feature/PR number and a link to a commit (in another branch or sandbox)
or a patch (diff -u) against the branch.
Tim Funk wrote:
What is a change? Any commit?
Is a change only for new features and bug fixes are out of scope?
My idea is to have it for all commits but only on release branches.
The idea is more to force people participating on the development of new
feature and help to fixing bugs.
Cheers
In that case
ballot
[ ] +1
[ ] 0
[X] -1
/ballot
For ensuring new features start in trunk and work their way back, I'd
+1. But since bugs (in BZ not marked as enhancement) would also need RTC
- that is my reason for -1.
-Tim
jean-frederic clere wrote:
Tim Funk wrote:
What is a change?
-1,
that means the entire tomcat project is RTC, since you just voted to get
rid of trunk
Filip
jean-frederic clere wrote:
Hi,
I would also propose that we take an handling of release branches
similar to httpd.
The release branches are:
/tomcat/tc6.0.x/trunk
/tomcat/build/tc5.5.x/
On Sep 4, 2007, at 4:53 AM, jean-frederic clere wrote:
Hi,
I would also propose that we take an handling of release branches
similar to httpd.
The release branches are:
/tomcat/tc6.0.x/trunk
/tomcat/build/tc5.5.x/
/tomcat/container/tc5.5.x
/tomcat/jasper/tc5.5.x/
(Note it uses
Filip Hanik - Dev Lists wrote:
-1,
that means the entire tomcat project is RTC, since you just voted to get
rid of trunk
Personally, using the CTR model, I noticed a number of people always
considered the R portion invalid, and useless chatter that is best
ignored. My take on the situation
Jim Jagielski wrote:
I'm +1 for this type of procedure, but I don't see how
this can be shoehorned into the current setup and layout
of TC.
The basic ideas behind httpd and apr are:
o There is a set development location (currently trunk)
which operates under CTR.
o There is a set
Remy Maucherat wrote:
Jim Jagielski wrote:
I'm +1 for this type of procedure, but I don't see how
this can be shoehorned into the current setup and layout
of TC.
The basic ideas behind httpd and apr are:
o There is a set development location (currently trunk)
which operates under CTR.
44 matches
Mail list logo
