Friday, July 23, 2010

Patch submission

Working in a central tech development role I have patches sent to me on a regular basis, patches for which I am grateful to receive because being able to adopt the fixes my users make only improves my products.

That said, here is my wishlist for patch submission nirvana:
  1. Describe the problem the patch is meant to solve. Maybe a patch isn't entirely necessary? No matter what, dropping a handful of files on my lap with no explanation as to what they do is going to waste both my time and yours as I will need to figure out what's going on, and you're going to be helping!
  2. Please send diffs, not whole files.
  3. Use unified diffs (diff -u or, with Perforce, p4 diff -du). Non-unified diffs are very hard to follow context-wise. The old-style Perforce visual diff that stylizes the old text with bold, red, and struck out and the new text with bold blue is even worse. Providing a patch set or a Git branch would be the Bestest(tm).
  4. If it isn't possible to provide a Git branch then at least indicate from which version of the library the patch was written against.
  5. If I reject the patch, it's not because I don't like you, it may be that the patch conflicts with design goals of the library or may be tied too closely to the submitter's own parent project. This code serves many people and I need to ensure that no one is hindered by the application of this patch.
Thanks, in advance :)

No comments:

Post a Comment