Re: Lessons from commit fest

Hi, <br /><br /><div class="gmail_quote"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204,
204);margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div class="Ih2E3d">>  The idea that we "fix" stylistic issues
onthe fly is not sustainable.<br /> >  We should offer help and mentorship to new patch submitters in all<br /> >
 areas(including stylistic) but they should do the work. It is the only<br /> >  way we will mold them to submit
patchesin the proper way.<br /> ><br /><br /></div>I agree.  As a submitter I would much rather get an email saying
e.g.<br/> "Hey, your patch is nice but the code style sticks out like a sore<br /> thumb.  Please adopt surrounding
namingconvention and fix your<br /> indentation per the rules at [link]." than have it fixed silently on<br /> its way
tobeing committed.<br /><br /> With the former I learn something and get to improve my own work.<br /> With the latter,
mynext patch is probably going to have the exact<br /> same problem, which is in the long term just making extra work
forthe<br /> reviewers.<br /><div class="Ih2E3d"></div></blockquote></div><br />I think, us patch-submitters should be
askedto do a run of pg_indent on the files that we have modified. That should take care of atleast the indentation
relatedissues. I looked at the README of src/tools/pgindent, and it should be easy to run enough (or is it not?). Only
onething that caught my eye was:<br /><br />1) Build the source tree with _debug_ symbols and all possible configure
options<br/><br />Can the above point be elaborated further? What all typical and possible configure options should be
usedto get a clean and complete pg_indent run?<br /><br />And I think adopting surrounding naming, commeting, coding
conventionsshould come naturally as it can aide in copy-pasting too :)<br /><br />Regards,<br />Nikhils<br />-- <br
/>EnterpriseDB<a href="http://www.enterprisedb.com">http://www.enterprisedb.com</a>