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
call.
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.
Filip
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
