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/)
