SteveKing <email@example.com> writes:
> 1. A three line patch making authentication work on Win98/Me systems
> because there the get_UID() function doesn't work:
> Got rejected because it would belong into apr. But now, the
> authentication does exactly this - a little different of course
> because the whole auth stuff has been rewritten since then.
> 2. A bigger patch to make Subversion build as a dll on windows to
> avoid static linking:
> Got rejected because (even though the patch uses the exact same
> approach as apr does) it wasn't the way the devs wanted it done. A
> generator for def files was the choice, but Subversion doesn't build
> as a dll even almost two years later...
> So you might see now why I don't write patches for Subversion
> anymore. I would just spend a lot of time which most likely would be
> for nothing -
> I'd rather spend that time on TSVN where I know it will do some good.
Stefan, I'm sorry you've had these experiences, but if you look
outside the horizons of what's happened to you personally, you have to
admit that we apply a LOT of patches from non-committer contributors.
If your patches get rejected more frequently than other people's, I
don't know what the reason is. It's certainly not prejudice -- if
anything, we're biased toward making you happy, because TSVN is so
It could be that you tend to tackle hard, complex problems where
different people have very different approaches to the solutions.
(The DLL thing might be an example of that, though I'm not
knowledgeable enough about the problem to say for sure.) When you
have posted reports and/or simple patches for obvious bugs, we have
dealt with them promptly: r6664, r6175, r5936, r5190, and r4823 for
So please don't just give up. Instead, try to guess whether a patch
is likely to be simple and non-controversial, or likely to lead to
long discussions. If you know the latter in advance, that might at
least prepare you mentally for what's ahead.
For what it's worth, I've made plenty of proposals for fixes recently
that have gone nowhere. Either people disagreed with the overall
approach, or they pointed out problems with the proposal that I didn't
see at first, or whatever. So it's not just you -- it's the nature of
the problem. Subversion has M developers and N things that need
doing, where M < N by a large factor. We have to prioritize.
To unsubscribe, e-mail: firstname.lastname@example.org
For additional commands, e-mail: email@example.com
Received on Fri Jan 14 19:28:45 2005