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 be
[ ] +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-tune
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,
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
>> patch
+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:
[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
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:
--
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
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:
> >
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 follow
+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 inst
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:
- The
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 s
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
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
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 prop
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 7
+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.
> >[
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 pr
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:
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:
--
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
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 tha
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,
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
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 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
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
> >
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
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
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 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
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
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 neede
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 commi
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
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 withi
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 ki
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 hav
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 wi
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 e
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 rea
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, watc
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
+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. Throu
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.
No
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
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 rea
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 ev
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
proble
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
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 o
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.
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. Peop
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
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
T
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 ou
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 c
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 Ha
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 disa
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,
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 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 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 wha
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) vot
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 misunderst
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
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 an
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
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 tomca
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 solutio
"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 immed
"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 c
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 di
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 cre
"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 precis
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/impr
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
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.
>
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 a
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
+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 draf
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
+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 )
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
pr
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
>> programma
+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
> -
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 wh
+1
-Tim
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
+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
Hey,
On 9/18/07, Remy Maucherat <[EMAIL PROTECTED]> wrote:
> Another more precise draft.
> 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 notice
91 matches
Mail list logo
