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

Re: Merging r9254

From: Branko Čibej <brane_at_xbc.nu>
Date: 2004-04-18 09:50:03 CEST

kfogel@collab.net wrote:

>Ben Reser <ben@reser.org> writes:
>
>
>>Ohh yeah one other thing I forgot. We're voting on changes based upon
>>the change on trunk. Problem is people look at the diff on trunk and
>>then vote on that. Then when we go to merge we run into situations
>>where other changes that were necessary didn't get nominated, which
>>means we're looking for people to review them at the last minute. This
>>can't be good for quality.
>>
>>
>
>Wow, that's a good point.
>
><musing out loud...>
>
>We don't want to waste time generating patches (and filing issues to
>hold them) that don't really differ from the corresponding revisions.
>
>Maybe it would be good to divide the release process into stages, even
>if it means releases take a bit longer:
>
> 1. Nomination and voting period.
> 2. Trial merges.
> 3. Creation of patches where necessary, as revealed by step 2.
> 4. Last voting round, includes the patches (which have issue numbers).
>
>To ensure termination, have a policy that new nominations which come
>in after stage 1 don't have to go into this release, they can go into
>the next one.
>
>
We could also make things simpler by creating a 1.0.x-staging branch
(from 1.0.x, of course). Anyone who has a candidate change merges it
from trunk to 1.0.x-staging and proposes _that_ commit. Those changes
should always apply cleanly to 1.0.x.

After a release, we merge form 1.0.x back to the staging branch.
Candidates that got punted to a later patch remain there, those that got
vetoed can be removed from the staging branch.

This keeps patch candidates in the repository where they belong, instead
of scattered throughout the mailing list, and has the advantage that
potentially conflicting changes can be tested together before they go to
the release branch, keeping 1.0.x as clean as possible.

-- Brane

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sun Apr 18 09:49:58 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.