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

Re: svn commit: r1343456 - in /subversion/branches/javahl-ra/subversion/bindings/javahl/native: RevpropTable.cpp RevpropTable.h

From: Hyrum K Wright <hyrum.wright_at_wandisco.com>
Date: Tue, 29 May 2012 20:04:24 -0500

On Tue, May 29, 2012 at 4:11 PM, Daniel Shahaf <d.s_at_daniel.shahaf.name> wrote:
> Greg Stein wrote on Tue, May 29, 2012 at 16:28:19 -0400:
>> I would suggest any logical change that can apply to trunk should be
>> submitted to dev@. If it helps trunk, or is at least neutral, then I'd
>> support it.
>> We couldn't digest your initial 27 patches :-), but some minor ones showing
>> up should be just fine. I would guess you'll be looking for a +1 from Mark
>> or Hyrum. Most others don't really know JavaHL :-(
> Why don't we ask Vladimir to commit patches to the branch and then ask
> for a +1 to cherry-pick them to trunk?
> He could even maintain a STATUS file in the branch of revisions
> nominated for cherry picking...

So you're suggesting a change in policy from the traditional method of
committing stuff directly to trunk (after the requisite +1 from a full
committer, if required)?

I think the dev@ + review technique we've historically employed is
better for a couple of reasons. Firstly, it ensures stuff gets to
trunk by the quickest route possible, and encourages the contributor
to work with the community. Second, it also ensures that the code
will be released, even if the branch doesn't pan out. Thirdly, I
think it gives the contributor more visibility, and hopefully
encourages reviewers to offer the relevant commit access more rapidly.

In light of those reasons, I still prefer Vladimir to submit generally
relevant patches to dev@ for commit to trunk, rather than commit to
the branch and pull them from there. (And this isn't specific to just
this instance of course.)


uberSVN: Apache Subversion Made Easy
Received on 2012-05-30 03:04:57 CEST

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