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) vote if one still wants to have a discussion
about ideas?
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.
2. RTC:
Seen as bad because it slows development down.
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.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
