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 g...@2ndquadrant.com 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
