tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Filip Hanik - Dev Lists <>
Subject Re: Review model take 2
Date Thu, 20 Sep 2007 18:51:29 GMT
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 other hand, why call
> There is "draft" written in the subject of the email.
>> for a (premature) vote if one still wants to have a discussion
>> about ideas?
> This has been under discussion for weeks, I would say it is time to 
> wrap things up at some point.
>> Quite frankly, the 2 normal methods of doing code development
>> are seen as bad for the following reasons:
>>   1. CTR:
>>      Seen as bad because it allows for someone to go off
>>      on their own tangent.
>>      How it really works: Anyone committing code during this
>>      process must be aware that a later-on review of the
>>      patch may require it to be either patched, substantially
>>      modified or removed all together. If the patch has
>>      far reaching effects, it would be best to, before
>>      applying, discussing it on dev@ and achieving some sort
>>      of consensus (even lazy) that you aren't wasting your
>>      time. But you must be prepared to, worse case, back it
>>      out if need be. This implies, of course, that the rationale
>>      for the veto is justifiably technical, with a technical
>>      and objective basis. Enables faster development on a
>>      community codebase.
> Yes, but the only thing that really happens is a flame war to debate 
> if the veto (which is a far too broad and absolute tool for review) is 
> valid. So maybe it works in some situations, but at this point I don't 
> see how a generic gentler review mechanism would hurt.
>>   2. RTC:
>>      Seen as bad because it slows development down.
> Actually, nobody mentions this anymore. The only remaining specific 
> "issue" that was mentioned is being able to block a particular change. 
> As far as I am concerned, this is not any different from a veto, 
> except that more people would have to review something negatively to 
> block things up.
>>      How it really works: Avoids the possible huge disruption
>>      when a patch needs to be reversed. Ensures sufficient
>>      community acceptance of implementation and patch to
>>      justify the effort in creating it. Ensures stable
>>      branch remains stable.
>> If there was a better underlying feeling of trust here, as
>> well as concerted effort to make development communal as well
>> as not abuse the veto power, then a lot of this discussion
>> and crafting of hybrid development methods with explicit
>> rules would likely not be required.
> This is true. For starters, as I stated on the PMC list, I think that 
> one person should not remain as a committer (and I will obviously 
> ignore all his posts until further notice).
interesting, and this "new process" is supposed to solve the attitude 
deficiency described in the line above.
fundamentally if you have a personal issue, there are no means that the 
issue will be solved until you move on and put it past you.

so you tried to kick me out as a committer, and that didn't work for 
you, too bad, maybe it would have been easier that way, but it wasn't my 

But hey, it didn't work out your way, deal with it in an appropriate 
way. I'm one of the few who's stepped up and challenged the flood of 
vetoes that comes from your corner, most of them with simple one line 
personal statement behind them, and for that, you think I no longer 
belong in the Tomcat community. That would make the community 
hierarchical, wouldn't it?

There are two things that can happen
1. Encourage more discussion - see my other email
   For this to happen, the responses need to be thought out. If you 
think about it, why people are not discussing it, could be cause they 
dont want to deal with the one line responses

2. Vetos need to be done in the ASF way, not in the old Tomcat way.


> There's also a general behavior of not discussing fairly significant 
> changes before committing (even on release branches). If general good 
> behavior rules and processes were not needed, the ASF would have none 
> and rely exclusively on good will. It's obviously not the case, and 
> we're here discussing a review model to better address the project's 
> specific needs.
> Rémy
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

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

View raw message