From: | Hitoshi Harada <umi(dot)tanuki(at)gmail(dot)com> |
---|---|
To: | Dimitri Fontaine <dfontaine(at)hi-media(dot)com> |
Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Peter Eisentraut <peter_e(at)gmx(dot)net>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: commit fests |
Date: | 2010-01-23 14:14:32 |
Message-ID: | e08cc0401001230614n63f66f21n913b3599a3b1179c@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
2010/1/23 Dimitri Fontaine <dfontaine(at)hi-media(dot)com>:
> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
>>> I agree with trying to cut down the submission-to-commit delay, but
>>
>> It seems to me that the CommitFest process is pretty darn effective at
>> reducing the submission-to-commit delay, except when you miss the last
>> one for the release - then it sucks hard.
>
> Too bad we can't have a release management team (with committers,
> testers, advocacy, doc writers, etc) taking care of the beta to release
> road while the first commit fest(s) for next release happen in parallel.
>
> It would move the primary goal of a commit fest from committing patches
> to reviewing them (return with feedback or stamp ready for a committer),
> reducing the chances that anyone will have some time to handle the last
> step.
>
It seems to me that recent discussions pass over this point. At least
for me, the commit fest is to review patches and give authors feedback
in not-so-long time after posting them. I like this idea.
Regards,
--
Hitoshi Harada
From | Date | Subject | |
---|---|---|---|
Next Message | Kevin Grittner | 2010-01-23 14:48:03 | Re: Largeobject Access Controls (r2460) |
Previous Message | Dimitri Fontaine | 2010-01-23 13:05:24 | Re: commit fests |