Re: Commitfest Bug (was: Re: Reusing abbreviated keys during second pass of ordered [set] aggregates) - Mailing list pgsql-hackers

From Magnus Hagander
Subject Re: Commitfest Bug (was: Re: Reusing abbreviated keys during second pass of ordered [set] aggregates)
Date
Msg-id CABUevEwoeCGoBo5zKDM5AxuiY-CvF1+rrfs+VWyDK5UBijW4EA@mail.gmail.com
Whole thread Raw
In response to Re: Commitfest Bug (was: Re: Reusing abbreviated keys during second pass of ordered [set] aggregates)  (Pavel Stehule <pavel.stehule@gmail.com>)
Responses Re: Commitfest Bug (was: Re: Reusing abbreviated keys during second pass of ordered [set] aggregates)  (Alvaro Herrera <alvherre@2ndquadrant.com>)
List 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?
 
--

pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Addition of extra commit fest entry to park future patches
Next
From: Magnus Hagander
Date:
Subject: Re: Addition of extra commit fest entry to park future patches