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

Magnus Hagander wrote:
> On Tue, Feb 16, 2016 at 11:12 PM, Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
> wrote:

> > 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 :)

I guess the "move to next CF" operation is new enough that we didn't yet
know what was the most useful behavior.

> 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?

I think the states "Ready for Committer" and "Needs Review" ought to be
kept in the new CF.

I'm unclear on what to do about "Returned with Feedback" and "Waiting on
Author"; my first instinct is that if a patch is in those states, then
it shouldn't be possible to move to the next CF. On the other hand, if
we force the state to change to "Needs Review" before moving it, we
would lose the information of what state it was closed with. So perhaps
for any patch in those two states, the state in the next CF should be
"needs review" too.

I am even more unclear on "Rejected". My instinct says we should refuse
a move-to-next-cf for such patches.

--
Álvaro Herrera http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services