tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From jean-frederic clere <>
Subject Re: Review model take 2
Date Thu, 20 Sep 2007 14:34:55 GMT
Filip Hanik - Dev Lists wrote:
> Bill Barker wrote:
>> "Filip Hanik - Dev Lists" <> wrote in message
>>> 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
>>>>>>>> programmatically
>>>>>>> yes, makes sense
>>>>>>>> - any other commit for which a committer asks for the RTC
>>>>>>>> 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
>>>>>>> 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
>>>>>> 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
>>>>>> 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.



+++ CUT +++

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message