On Tue, May 29, 2012 at 4:11 PM, Daniel Shahaf <d...@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.) -Hyrum -- uberSVN: Apache Subversion Made Easy http://www.uberSVN.com/
