[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

no more need for a mergemaster

From: <kfogel_at_collab.net>
Date: 2004-01-16 02:45:46 CET

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
Received on Fri Jan 16 03:41:12 2004

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.