"D.J. Heap" <dj@shadyvale.net> writes:
> However, since this is for 1.0.x, I don't want to commit it to trunk,
> obviously, and I'm not sure whether or not this kind of patch requires
> voting on for the 1.0.x branch...Karl (or someone), should I put it up
> for voting in the STATUS file with a pointer to the email or what?
Is there some reason we wouldn't commit it to trunk first, then merge
the change over to 1.0.x? The change is as good on trunk as it is on
1.0.x, I would think.
The normal way to do this is to commit it to trunk, then either add an
item in the STATUS file to vote on merging the change, or merge it
over directly if voting is not required.
Martin Tomes wrote:
> My understanding is that as this will not affect the code at all then
> it can go in without going through the STATUS file procedure. In the
> run up to the 1.0 release patches against documentation were accepted
> right up to the release date.
That's right, in this case voting is not required, so D.J. can just
merge the trunk change right into 1.0.x. See the section "Stabilizing
and maintaining releases" in the HACKING file for details about this.
Sometimes, even when voting isn't technically required, it's still a
good idea to give people a chance to review the change. In this case,
I don't think there's any benefit to waiting -- the change is a clear
improvement, so might as well get it in. People can still review it
and make more tweaks, after all.
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Apr 27 18:00:03 2004