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). 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]
