no more need for a mergemaster

[kf...@collab.net]

I thought it would be best if one person did all the merging into
1.0-stabilization at first, because some of the changes were
interrelated and wanted coordination.

That was probably necessary for big mergefests like r8228 and r8310,
but now that that stuff's all done, I doubt there will be more
mergefests.  More likely we'll just have one small change at a time,
for the rest of the stabilization process.  So I'm stepping down as
self-appointed mergemaster (the sequence of r8327, r8328, r8329
demonstrate it was high time anyway :-) ).

My suggestion is that we work like this from here on out:

Whoever casts the deciding vote on a change just go ahead and do the
merge, if you want.  You can remove the item from STATUS in the same
commit as the merge of the change itself -- just be sure to list your
name in the "Approved by:" field in the log message.  See previous
merge commits for examples, such as r8338, r8330, r8330, etc.

If you don't have time, or don't feel comfortable merging the change,
that's fine too.  Just commit your vote in STATUS; and other
committers should just feel free to "make it happen" once an item is
approved.

Please use appropriate judgement about controversial items.  For
example, r8339 was pretty obvious, so I didn't feel a need to wait a
day for potential vetoes when it had three votes.  On the other hand,
if a big change (such as the apr_off_t stuff) were to get three +1's
within five minutes of being put in STATUS, that doesn't mean it
should be merged right away.  Give people a day or so to examine it
first :-).

Comments welcome,
-Karl

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: no more need for a mergemaster

[Greg Stein <gs...@lyra.org>]

On Thu, Jan 15, 2004 at 07:45:46PM -0600, kfogel@collab.net wrote:
>...
> Please use appropriate judgement about controversial items.  For
> example, r8339 was pretty obvious, so I didn't feel a need to wait a
> day for potential vetoes when it had three votes.  On the other hand,
> if a big change (such as the apr_off_t stuff) were to get three +1's
> within five minutes of being put in STATUS, that doesn't mean it
> should be merged right away.  Give people a day or so to examine it
> first :-).

There is no such thing as a statute of limitations -- there isn't a rule
that says "well, it has been in there for X days, or Y months, so it gets
to stay". Bad code is bad code. So even though some code is committed, it
can *still* be vetoed and pulled back out.

Regardless... yes, it is polite to at least give people 72 hours to review
a vote. That is usually sufficient time for people to see the issue --
despite whatever time zone they may be in, or whatever personal time sink
has pulled them away.

Cheers,
-g

-- 
Greg Stein, http://www.lyra.org/

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org