this email is so unclean, I'm a bit confused on the exact bullets, mind
posting a new thread?
Filip
Jim Jagielski wrote:
On Sep 21, 2007, at 4:36 PM, Jim Jagielski wrote:
On Sep 21, 2007, at 4:27 PM, Costin Manolache wrote:
On 9/21/07, Jim Jagielski <[EMAIL PROTECTED]> wrote:
Just propose a polite way to move from the commit for a controversial
change ( i.e. when someone feels strongly it's going to the wrong
direction,
even
if technically code is ok ) to the majority and 3+1 process - and
we're
done.
As you know - some people are complaining that veto is abused ( and
that's
right ),
many Rs turn into flame wars and get personal - so the issue is how
to avoid
a technical code discussion for a non-technical or subjective issue.
First, it's important to recall that whether under CTR or RTC,
there is always Review. If people, after something has
been committed under CTR has issues with it, then
that is Reviewing it after all. We already discussed
technical voting, but what about "direction" or "vision"
review. Or, as you said in a previous Email:
... a polite way of saying:
"Hey, nothing wrong with the code itself, but I don't think there
is enough
support from
the community for the direction you're going - could you confirm
that a
majority and
at least 3 people think it fits our goals ?"
That's still part of the review process... Vetoes are
there to prevent code from being committed, but not
all reviews are for the functional aspects of the
actual code but rather to determine how much support
there is for an implementation or feature... So I would
say that this is still a valid and expected part
of the R in *both* CTR and RTC.
The thing is, of course, one cannot veto code based
on non-technical reasons, but one can certainly review
it based on such reasons and ask for some guidance that
it makes sense. IMO, most of those types of cases
should fall into the following types:
1. People who agree and will help support it,
implement it, etc... (+1)
2. People who don't care one way or another. (+0)
3. People who don't like it, but hey, if it helps
you out and there are other people behind it,
I won't stand in your way. (-0.9)
4. I don't like it and this is why. It would be
a mistake. (-1)
+1
If possible, add 5 and 6:
5. I may like it, but as a module that is not enabled by default.
6. I may like it, but as a standalone module, easy to download and
install,
but not bundled
in the base distro.
Assuming some sort of module impl exists, yes, of course.
Both 5 and 6 should be counted as -0.9 on the change itself, but as
+0.9 if
the
concern is addressed.
Yes, if everyone understand this - and we stop using early commit/lazy
consensus
and veto to get around R by a larger set of people - big +1.
I like CTR and having an official trunk where active development
happens -
but I don't like the endless discussion about veto validity and some
big
changes
made without consensus or consultation - that was the main reason I
support
a partial RTC until people get used to the idea of getting a +3 for
important changes.
Costin
I think all this handles the obvious and some of the non-obvious
holes that had been in place...
I'd like to call a vote on acceptance of the above methodology,
as crafted and fine-tuned by Costin and myself. It is worthwhile
to note that, really, these are the typical ASF methods, but
with some "grainy" aspects better defined. In essence, some
typical "niceties" are now mandated (changes, even in CTR, which
affect the API, must be brought up first to gauge community
approval).
[ ] +1. Yes, the above works and addresses my concerns
as well as the problems which started this whole
thing.
[ ] 0. Whatever.
[ ] -1. The above does not work for the following reasons:
The vote will run for 96 hours instead of the normal 72 because of
the weekend. Only binding votes will be counted, but non-binding
votes will be used to address wider concern/acceptance of
the proposal.
---------------------------------------------------------------------
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]
