Peter Eisentraut wrote:
> I think it's better to share code that doesn't mean project guidelines
> and solicit advice rather than not to share anything.
>
I feel the assumption that code is so valuable that it should be shared
regardless of whether it meets conventions is a flawed one for this
project. There are already dozens, if not hundreds, of useful patch
submissions that have been sent to this list, consumed time, and then
gone nowhere because they didn't happen in a way that the community was
able to integrate them properly. For anyone who isn't producing
commiter quality patches, the process is far more important than the
code if you want to get something non-trivial accomplished.
Also, producing code in whatever format you want and dumping that on the
community so that people like David Fetter waste their time cleaning it
up is not the way the GSoC work is supposed to happen. I didn't want
any other current or potential future participants in that program to
get the wrong idea from that example.
There is a brief "get to know the community" period at the beginning of
the summer schedule. I think that next year this project would be well
served to give each student a small patch to review during that time, as
a formal intro to the community process. The tendency among students to
just wander off coding without doing any interaction like that is both
common and counterproductive, given how patches to PostgreSQL actually
shuffle along toward becoming commit quality code. Far as I'm
concerned, a day spent working with the patch review checklist on
someone else's patch pays for itself tenfold when it comes time to
produce patches that others will be able to review.
--
Greg Smith 2ndQuadrant US Baltimore, MD
PostgreSQL Training, Services and Support
greg@2ndQuadrant.com www.2ndQuadrant.us