[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: Daniel Shahaf <d.s_at_daniel.shahaf.name>
Date: Wed, 30 May 2012 07:01:25 +0300

Hyrum K Wright wrote on Tue, May 29, 2012 at 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'm just trying to get out of Vladimir's way. Via the "branch STATUS
file" approach he can parallelize (a) his work, (b) merging it ---
having N merge threads open would be harder to track.

He'll still have to work with us, just differently.

Daniel

> 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.)
>
> -Hyrum
>
>
> --
>
> uberSVN: Apache Subversion Made Easy
> http://www.uberSVN.com/
Received on 2012-05-30 06:02:11 CEST

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