Today we begin deciding which fixes go into 1.0 and which don't (let's
wait until the 1.0-stabilization branch is created, though).
I have a vision for how voting will work, and what the votes mean,
which I hope can give us some guidance.
First, do not vote +1 on a change just because you understand what the
issue is and would like to see it fixed for 1.0. In other words,
*don't* just run down the list in one pass and mark everything you
like. If we operate that way, it will simply guarantee that every
candidate issue finds at least three approvals and gets committed.
Instead, a +1 vote should mean that:
1. You are convinced if this is not fixed for 1.0, it will be much
more painful to deal with afterwards. Various UI and/or API
changes probably meet this criterion, but a plain bug fix might
not, for example.
2. You have personally reviewed every line of the proposed change,
and are willing to take equal responsibility with the original
author for it. If you vote +1, your name will go in the log
message along with the original author's, and you should be as
willing to answer for any bugs that result. If you don't have
the expertise to evaluate a change, then please don't vote on it
(you can still add a comment saying why you think it should go
in, and encouraging domain experts to give it consideration).
As for the logistics:
Mention your committer name when you vote, if it's different from your
tigris.org username, and don't forget to adjust the "votes:N" field in
the issue's StatusSummary.
In addition to the vote itself, explain briefly why you have voted for
(or against) the change. Followup discussion should happen on the dev
list, though.
If someone votes "-1", that's a veto, and it means the change doesn't
go in without at least some more discussion on the dev list.
Eventually, a straight vote can break a veto, but that should be a
separate process undertaken consciously.
We don't want to descend into a veto war, naturally (I'm hoping to get
all the way through it without any vetos). But to achieve that also
requires a certain amount of conservativism from everyone in making
positive votes. For example, take time to consider carefully whether
there's any way to achieve the desired API change after 1.0 without
breaking compatibility -- often there is.
By the way, I think it's best to have one person merging the changes,
since it's easier for one brain to keep track of potential conflicts
and do things in a sane order. I'm guessing the voting process will
take a week or so. When the final issue list is settled, I volunteer
to be Mr. Merge (I'm not traveling for the holidays anyway, so that'll
be a good time to take care of this, with not much else going on).
Following this mail, I'll make some separate posts about certain
individual issues and why I think they don't need to be solved for
1.0.
Thanks,
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Dec 19 18:48:48 2003