On Mon, Feb 8, 2010 at 11:47 AM, Dimitri Fontaine <dfonta...@hi-media.com> wrote: > Robert Haas <robertmh...@gmail.com> writes: >> On Mon, Feb 8, 2010 at 10:25 AM, Alvaro Herrera >> <alvhe...@commandprompt.com> wrote: >>> Eh? Previously we allowed code to go in with documentation to be >>> written after feature freeze. Is this no longer acceptable? >> >> I don't think we usually allow that for minor features. For big >> things, it's probably more reasonable, but I would think that at least >> some effort should be put in before commit. I'm new here, though, so >> I might be all wet. But I wouldn't want to commit ten patches without >> documentation and then have someone come back and say, OK, you >> committed 'em, you write the docs. Or else no one comes back, and I >> forget, and it never gets done. > > Well, traditionnaly, we had Bruce to sort those things out. But in this > case the problem is not so much about writing documentation than > deciding where to put it and what to explain exactly. I think. > > Anyway saying the patch can not be considered by a commiter for only > lack of complete documentation is not a policy here, IME. It can happen, > but I would consider it bad news if it were to become a way to force the > release timeframe. What is hard is doing *good* compromises.
Of course any committer can consider any patch whenever they like, regardless of how it is marked on commitfest.postgresql.org, right? And there has been no shortage of committers doing just that; 80%+ of the reviews for this CommitFest were done by committers. But I'm not going to spend the time to write the docs for somebody else's patch unless I really care about seeing it go in; other committers are free to do as they like, of course. ...Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
