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

Re: svn commit: r30811 - branches/1.5.x

From: Hyrum K. Wright <hyrum_wright_at_mail.utexas.edu>
Date: Mon, 28 Apr 2008 10:23:37 -0500

Kamesh Jayachandran wrote:
> Hyrum K. Wright wrote:
>> arfrever_at_tigris.org wrote:
>> > * Apply patch at,
>>> http://subversion.tigris.org/servlets/ReadMsg?list=dev&msgNo=137828
>>> Fixes compiler warning, which has been introduced while resolving the
>>> conflict from merge of r30633 from trunk.
>>> Votes: - +1 kameshj
>>> + +1 kameshj, arfrever
>> Hmmm. Instead of voting to apply the patch at that address, perhaps we
>> should create a branch, apply the patch to the branch, and then vote on
>> the branch? It seems a bit easier for people to review, and a bit more
>> inline with our process. Of course, if we want to change the process,
>> that's fine, too. :)
> Why should we have short-lived-branch to track one trivial-item specific
> for 1.5.x alone and merge later, why not rather directly commit it after
> approval.

You're right, it's trivial and probably doesn't matter a whole lot.
But...something just doesn't seem right about committing directly to a
stabilization branch, particularly during the RC soak period. I agree
that the problem should be fixed, and that this patch looks like the
right way to do it, I'm just questioning whether or not we should bend
(or modify) our typical, albeit nebulous, process in this instance.

Branches are cheap, merging is easy, so why *not* create a short-lived
branch to track this patch, just like we do with conflicting merges from

(That being said, do what you will. I'm not going to veto this
particular change, but I did want to express my concerns.)


Received on 2008-04-28 17:23:58 CEST

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.