With another round of GSoC submissions approaching, I went looking
around for some better guidance on the topic of how to follow terse
submission guidelines like "blend in with the surrounding code" or
"remove spurious whitespace". And I didn't find any. Many mature
open-source projects say things like that, but I haven't been able to
find a tutorial of just what that means, or how to do it.
Now we have http://wiki.postgresql.org/wiki/Creating_Clean_Patches to
fill that role, which fits in between "Working with Git" and "Submitting
a Patch" as a fairly detailed walkthrough. That should be an easier URL
to point people who submit malformed patches toward than the
documentation we've had before.
Advocacy aside: this page might be a good one to submit to sites that
publish open-source news. It's pretty generic advice, is useful but not
widely documented information, and it reflects well on our development
practice. I'm trying to reverse the perception we hear about sometimes
that submitting patches to PostgreSQL is unreasonably difficult. Seeing
an example of how much easier it is to read a well formatted patch
serves well for making people understand why the project has high
expectations for formatting work. It's not pedantic, it's functionally
better. I threw it onto reddit as a first spot to popularize:
http://www.reddit.com/r/technology/comments/hy0aq/creating_clean_patches_with_git_diff/
--
Greg Smith 2ndQuadrant US g...@2ndquadrant.com Baltimore, MD
PostgreSQL Training, Services, and 24x7 Support www.2ndQuadrant.us
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
