Daniel Shahaf wrote on Fri, Sep 24, 2010 at 18:35:32 +0200:
> C. Michael Pilato wrote on Fri, Sep 24, 2010 at 10:27:35 -0400:
> > On 09/24/2010 08:46 AM, Geoff Rowell wrote:
> > > Is it too late to backport it for the upcoming release?
> >
> > It's not about the timing, really. We don't introduce new features in patch
> > releases. Now, that said, svnmucc isn't really part of our core product, so
> > perhaps it doesn't fall into this restriction. I wonder what other devs
> > think about this?
>
> I'm fine with backporting patches that, formally, add a new feature
> (e.g., a new --option flag), given that they are localized and not
> overly invasive. (I wouldn't support a backport that adds a new feature
> but rewrites half of the internals.)
Would svnrdump benefit if, once 1.7.x branched and RC's start being
rolled, it were subjected to a more relaxed backporting policy?
If so, we might consider moving it to tools/ for 1.7.x, with intent to
move it back to subversion/svnrdump/ for 1.8.x (as soon as 1.7.x is
branched from trunk).
Thoughts?
Daniel
(I still remember that two years ago we discussed moving svnmucc to
subversion/svnmucc/)
Received on 2010-09-24 18:52:05 CEST