|From:||Robert Haas <robertmhaas(at)gmail(dot)com>|
|To:||Kevin Grittner <Kevin(dot)Grittner(at)wicourts(dot)gov>|
|Cc:||Bruce Momjian <bruce(at)momjian(dot)us>, jd(at)commandprompt(dot)com, Peter Eisentraut <peter_e(at)gmx(dot)net>, pgsql-hackers(at)postgresql(dot)org, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>|
|Subject:||Re: 8.5 development schedule|
|Views:||Raw Message | Whole Thread | Download mbox|
On Wed, Jul 1, 2009 at 6:53 PM, Kevin
> Bruce Momjian <bruce(at)momjian(dot)us> wrote:
>> The problem is that the committers control the commit date, but the
>> one seen as punished for a rejected patch is not the committers but
>> the submitter.
> Well, it would seem odd for anyone to feel "punished".
Depends on who the patch submitter thinks is at fault. Sometimes,
patches legitimately don't get reviewed as much as would be good.
Other times, the submitter just thinks the committer is nitpicking. I
think Bruce summarized it pretty well.
Really, when you get right down to it, you can guarantee that all
patches get a certain amount of review, or you can guarantee that the
CommitFest ends by a certain date, but not both, because you can't
force other people to spend more time on PostgreSQL than they have to
spend. At best, you can get them to spend the time that they do have
on the right sort of things (e.g. reviewing rather than developing new
patches during CommitFest).
Of course, since you want both of those things to happen, it's a balancing act.
|Next Message||KaiGai Kohei||2009-07-01 23:59:58||Re: [PATCH] [v8.5] Security checks on largeobjects|
|Previous Message||Tom Lane||2009-07-01 23:30:44||HEAD is open for 8.5 development|