I will do as @dev decides.
But to give context, at the moment there are 14 patches with first two
already committed to the branch (mea culpa). 3 of the patches require
manual svn copy command to apply since svn patch does not support conveying
copy operation in the patch. Please don't be alarmed by the number of
patches, there are mostly small and each can be reviewed on their own.
From the perspective of the trunk they will be neutral. However about 3rd
of them can be used to reduce amount of code used in current JavaHL
implementation by factoring out commonly used code into macros. Rest are
about making code more generic so it can be used with the svn_ra_*
functions.
Hope this helps,
Vladimir
On Wed, May 30, 2012 at 12:01 AM, Daniel Shahaf <d.s_at_daniel.shahaf.name>wrote:
> 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 14:32:36 CEST