Re: branching for 9.2devel

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: branching for 9.2devel
Дата
Msg-id BANLkTikd2CF_J=5Ab9E1QKG_7XWqY_py8Q@mail.gmail.com
обсуждение исходный текст
Ответ на Re: branching for 9.2devel  (Steve Singer <ssinger_pg@sympatico.ca>)
Список pgsql-hackers
On Mon, Apr 25, 2011 at 4:29 PM, Steve Singer <ssinger_pg@sympatico.ca> wrote:
> On 11-04-25 03:40 PM, Robert Haas wrote:
>>
>> At the risk of getting a bit cranky, you haven't participated in a
>> material way in any CommitFest we've had in well over a year.  AFAICS,
>> the first, last, and only time you are listed in the CommitFest
>> application is as co-reviewer of a patch in July 2009, which means
>> that the last time you really had a major roll in this process was
>> during the 8.4 cycle.  So I'm really rather suspicious that you know
>> what's wrong with the process and how to fix it better than the people
>> who are involved currently.  I think we need here is more input from
>> the people who are regularly submitting and reviewing patches, and
>> those who have tried recently but been turned off by some aspect of
>> the process.
>
> I reviewed a handful of patches during commitfests during the 9.1 release.
>  I think  a commitfest lasting one week will make me review fewer patches
> not more.    At the start of a commitfest I would volunteer to review a
> single patch knowing that it wouldn't be hard to find 4-6 hours to review
> the patch during the next few weeks.   Once I was done with the first patch
> when I thought I'd have sometime in the next few days to review another
> patch I would pick another one off the list.   At the start of the
> commitfest I wasn't concerned about picking up a patch because I knew I had
> lots of time to get to it.  Near the end of the last commitfest I wasn't
> concerned about picking up an unassigned patch because there were so many
> patches people picked up earlier on in the commitfest waiting for review
> that I didn't think I'd get pressured on a patch I had only picked up a day
> or two ago.  If I knew I was expected to turn a review  around in a short
> window I think I would only pick up a patch if I was 90% sure I'd have time
> to get to it during the week. I sometimes can spend $work time on reviewing
> patches but I can rarely block time off or schedule when that will be, and
> the same somewhat applies to the patch reviews I do on my own time
> (postgresql stuff comes after other commitments).
>
> It is easy to say four weeks in a row "I won't have time to review one patch
> this week" it is harder to say "I won't have time to review a single patch
> in the next month"
>
> I also should add that sometimes I'd review a patch and the only issue from
> the review  might be "is this really how we want the thing to work?" and the
> commitfest app doesn't have a good state for this.  If patch needs feedback
> or a decision from the community and it sometimes isn't clear when enough
> silence or +1's justify moving it to a committer or bouncing the patch to be
> reworked.

Thanks for the input.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Steve Singer
Дата:
Сообщение: Re: branching for 9.2devel
Следующее
От: Robert Haas
Дата:
Сообщение: Re: Foreign table permissions and cloning