Mailers and attached patches

The patch submission policy to open source projects is about as diverse as the number of projects. One policy that comes up fairly often is, “Email submission to blah-developers@example.org. Entire message plain text only, with patch inline, not as an attachment.” Apparently this is so that someone, somewhere, using some sort of mail agent can review the patch while reading their email, and still save the patch cleanly to be applied.

Projects with this sort of policy tend to enforce it rather fanatically. It also means that the list is often covered in reposts of patches, and complaints, about, “Your mailer has mangled your patch (spaces to tabs or vice versa), please fix it and resend” or, “Your mailer has sent the patch as an attachment instead of inline, please resend.” or even just the friendly, “You’ve sent a html message, don’t do that

Really? That’s the world we’re living in? What mailer in the world won’t let you view a plain text attachment inline? We’re in some lowest common denominator worldview, where for half the people, the answer is NOT USE their email mailer, but an entirely separate program, just for sending patches. (git-send-email)

One the one hand, yes, this sort of policy keeps out amateurs. It also makes damn sure that no amateur ever gets any better. It makes sure that only previously established members can ever submit anything. It’s one of the least friendly ways of accepting work I’ve ever dealt with. And somehow this is OK. I say we’ve failed, and we’ve failed on purpose, and I don’t understand it.

Leave a Comment

NOTE - You can use these HTML tags and attributes:
<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>