[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Subversion Vision and Roadmap Proposal

From: Stefan Sperling <stsp_at_elego.de>
Date: Sun, 11 Apr 2010 10:57:41 +0100

On Sat, Apr 10, 2010 at 11:38:22PM -0700, Alexey Neyman wrote:
> 2. In the same issue, there is a reference to keyword substitution
> implementation used by FreeBSD. Again, no further description as to why this
> implementation was not acceptable, etc.

There was, in this thread:
If that thread isn't linked from the issue, it should be.
Could you add the link if it's not yet present there? Thanks!

> Given these two examples, I am somewhat afraid to invest my time into learning
> Subversion internals and coming up with such changes only to have them rot in
> the issue tracker indefinitely.

There's no reason to be afraid.
If you have a strong interest in getting your patches reviewed, they will
eventually be reviewed. If they pass review they will be committed
(committing isn't the hard part -- review is the hard part).
It takes some degree of patience and persistence on the submitter's behalf.
Maybe a bit much of it, which is certainly not ideal, because it makes
drive-by bugfixing quite hard. But if the submitter simply gives up
then the patch is very likely to get ignored. And if patches do get
ignored, the reason is not malicious intent of Subversion's developers.
The reason is that the patch failed to stay above the threshold of
developer attention, amidst the flood of other things developers need
to (and are expected to) spend their time on. There are more things
to do than people actively working on the code can reasonably handle
concurrently, so some sort of selection is bound to happen. But if you
are willing to invest time and energy into making sure your contributions
do not get lost, you will be rewarded for it (I know this first-hand
because I've gone through the same process before I became a developer).
The closer you get involved with the developer community the easier
submitting patches will be. E.g. it's a good idea to hang out in
the #svn-dev channel on Freenode to get an idea of who the developers
are, who is working on what, and who might have time or be interested
in reviewing your submissions.

Taking the FreeBSD custom-keywords example, this rots in the issue tracker
because the submitter himself said it wasn't ready for submission yet
(see thread I linked above). The patch is used locally at FreeBSD,
but they themselves consider it a hack. However, they seem to be happy
enough with it as is, and aren't interested in (or capable of, e.g. due
to lack of time) doing any additional work to get it into upstream Subversion.
It seems they'd rather hack their patch into the subversion 1.7.x FreeBSD
port when 1.7.x is released, rather than getting it into Subversion trunk
now. And that's unfortunate, but if they are happy with maintaining their
patch this way rather than pushing it upstream, we're not gonna try to
force them to push it upstream.

To get this work integrated upstream, someone (either an existing
Subversion developer, or a contributer) needs to take the patch,
port it to trunk, make sure it's sane and fit for general purpose use,
and commit/submit the result of that work. And that takes time.
If you have the time, please do so.

Received on 2010-04-11 11:58:55 CEST

This is an archived mail posted to the Subversion Dev mailing list.