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.
> 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 06:02:11 CEST