On Mon, Feb 8, 2010 at 11:47 AM, Dimitri Fontaine
<dfontaine@hi-media.com> wrote:
> Robert Haas <robertmhaas@gmail.com> writes:
>> On Mon, Feb 8, 2010 at 10:25 AM, Alvaro Herrera
>> <alvherre@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
