Re: Merging r9254

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.

-K

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Apr 16 23:23:58 2004