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: http://svn.haxx.se/dev/archive-2008-07/0113.shtml 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. Thanks, Stefan
