Re: Commitfest Bug (was: Re: Reusing abbreviated keys during second pass of ordered [set] aggregates)

Поиск
Список
Период
Сортировка
От Magnus Hagander
Тема Re: Commitfest Bug (was: Re: Reusing abbreviated keys during second pass of ordered [set] aggregates)
Дата
Msg-id CABUevEwoeCGoBo5zKDM5AxuiY-CvF1+rrfs+VWyDK5UBijW4EA@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Commitfest Bug (was: Re: Reusing abbreviated keys during second pass of ordered [set] aggregates)  (Pavel Stehule <pavel.stehule@gmail.com>)
Ответы Re: Commitfest Bug (was: Re: Reusing abbreviated keys during second pass of ordered [set] aggregates)
Список pgsql-hackers
Дерево обсуждения


On Tue, Feb 16, 2016 at 11:12 PM, Pavel Stehule <pavel.stehule@gmail.com> wrote:


2016-02-17 3:19 GMT+01:00 Jim Nasby <Jim.Nasby@bluetreble.com>:
On 2/16/16 12:38 AM, Michael Paquier wrote:
When a patch with status "Ready for committer" on CF N is moved to CF
(N+1), its status is automatically changed to "Needs Review". That's
something to be aware of when cleaning up the CF app entries.

I agree with Alvarro; this seems like a bug to me. If a patch is ready for committer in CF N, why would it suddenly not be ready in N+1?

+1,

This behave is pretty unpleasant and frustrating.


Well, it's in no way a bug, because it's the behavior we agreed upon at the time :)

That said, we can certainly reconsider that. Would we always copy the value over? Even if it was, say, rejected? (so it would be copied to the new CF but still marked rejected) Or is there a subset of behaviors you're looking for?
 
--
 Magnus Hagander
 Me: http://www.hagander.net/
 Work: http://www.redpill-linpro.com/

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

Предыдущее
От: Michael Paquier
Дата:
Сообщение: Addition of extra commit fest entry to park future patches
Следующее
От: Magnus Hagander
Дата:
Сообщение: Re: Addition of extra commit fest entry to park future patches