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. So
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
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
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
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 b
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 here?
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 automat
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 wo
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 specifi
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 o
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 rev7869
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 sp
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 rev7869
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
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
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 f
On Sep 6, 2007, at 1:39 PM, Mladen Turk wrote:
If you read my post I was careful enough to not mention the RTC
policy.
All I was saying is that current CTR caused too many problems,
because trunk was our stable branch, and disagreement on API
caused drastic things like putting trunk to sand
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 any
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 a
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 gi
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 tha
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
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 an
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.
>
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 o
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
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
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 requir
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 elab
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 pr
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 eve
Well what's the consensus on Java projects, like Xerces, Xalan or Lucene ?
2007/9/5, Remy Maucherat <[EMAIL PROTECTED]>:
> 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 a
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
poi
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 v
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 developm
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.
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 relea
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
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 /tomcat/connec
-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/
/tomcat/
In that case
> [ ] +1
> [ ] 0
> [X] -1
>
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? Any com
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.
Chee
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 bran
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)
/tomcat/build/bra
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 n
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.
> 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 descri
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
/tomcat/contain
47 matches
Mail list logo
