What you're saying when you tell people to send in patches
Exerpted from a comment on my entry about my problem with reporting CentOS bugs:
You could not be more wrong about your assumptions:
- Bugs.centos.org is community help .. meaning that our users and volunteer QA team answer questions there. Not only should you report bugs there .. you should also find and fix, the report the fix there. That is how open source works. You should fix the problem, report the fix to bugs.centos.org and bugzilla.redhat.com if you can .. I mean, you are getting the software for free, right?
When I read things like this, where people tell other people 'it's open source, you should be finding and submitting patches', this is how I expect those other people are reading it. Whether you realize it or not and whether you intend it or not, telling people 'submit a patch' is actually telling people 'go away, you annoying thing'.
(It's also sending the message that your project is only really for developers, who are the people who can actually come up with those patches. Mere mortals need not apply. For that matter, developers who have other things to work on need not apply either.)
Sometimes, occasionally, this is an appropriate thing to say. If someone is showing up in your bug report system to demand that you fix a bug (or is otherwise complaining loudly that an open source community is failing to do so), sure, go ahead and tell them to go away and shut up. Mind you, telling them a softball version of 'patch or GTFO' is kind of passive-aggressive; perhaps you could be more straightforward and just say 'we're not going to fix this, if you need a fix badly enough you'll need to do it yourself'.
But as a general reply? No. As a general reply or a general suggestion it's both rude and a bridge burner. It also hangs a kind of smug open source arrogance out for bystanders to see and take note of.
Oh, as a side note, saying this sort of thing is also kind of insulting in that it suggests (by implication) that someone with the capacity to create a fix has not realized that gosh, they could do it. Of course, there are people who don't think that they're good enough to create fixes or lack the confidence to do so and who need encouragement, but such gentle encouragement is not delivered in anything even vaguely close to this 'send patches' manner (any more than encouragement to submit bug reports is, cf the comments on this entry).
PS: this is one of the rare entries when I will say the following directly and explicitly: if you're thinking of being deliberately rude in a comment, either on this entry or elsewhere, go away. Enabling and hosting rudeness is not anywhere near why I have comments here and rude comments may be subject to summary removal if I am angry enough.
Sidebar: the toxic nature of 'that is how open source works'
I want to point the following out explicitly. If, to quote the comment, 'not only should you report bugs there .. you should also find and fix, the report the fix there. That is how open source works' is actually how open source works then the direct corollary is that open source is only really for developers, who are the only people who can actually find the source of bugs and fix them. Everyone else is a hanger-on and camp follower.
To put it mildly, I think that a lot of people in the open source world would strongly disagree with the view that their open source work is only or primarily for developers.
(I can't call this view a toxic one, although I want to. It's certainly toxic for wide use of open source, but if your view is 'open source is for developers' then you've already decided that you don't care about a wide use of open source.)
Porting to Python 3 by updating to modern Python 2
For quixotic reasons I decided to take a shot at porting DWiki to Python 3 just to see how difficult and annoying it would be and how far I could get. One of the surprising things about the process has been that a great deal of porting to Python 3 has been less about porting the code and more about modernizing it to current Python 2 standards.
DWiki is what is now a pretty old codebase (as you might guess) and even when it was new it wasn't written with the latest Python idioms for various reasons, including that I started with Python back in the Python 1.5 era. As a result it contained a number of long obsolete idioms that are very much not supported in Python 3 and had to be changed. Once the dust settled it turned out that modernizing these idioms was most (although not all) of what was needed to make DWiki at least start up under Python 3.
At this point you might be wondering just what ancient idioms I was still using. I'm glad you asked. DWiki was doing all of these:
raise EXCEPTION, STR' instead of '
raise E(STR)'. I have no real excuse here; I'm sure this was considered obsolete even when I started writing DWiki.
except CLS, VAR:' instead of '
except CLS as VAR:', which I think is at least less ancient than my
- using comparison functions in
reverse=True. Switching made things clearer.
- dividing two integers with '
/' and expecting the result to be an integer. In Python 3 this is an exact float instead, which caused an interesting bug when I used the result as an (integer) counter. Using '
//' explicitly is better and is needed in Python 3.
I consider this modernization of the Python 2 codebase to be a good thing. Even if I never do anything with a Python 3 version of DWiki, updating to the current best practice idioms is an improvement of the code (especially since it's public and I'd like it to not be too embarrassing). I'm glad that trying out a Python 3 port has pushed me into doing this; it really has been overdue.
(Another gotcha that Python 3 exposed is that in at least one place
I was assuming that '
None > 0' was a valid comparison to make and
False. This works in Python 2 but it's not exactly a
good idea and fixing the code to explicitly check for
None is a
good cleanup. Since this sort of stuff can only really be checked
dynamically there may be other spots that do this.)