Re: Commitfest Bug (was: Re: Reusing abbreviated keys during second pass of ordered [set] aggregates)
От | Tom Lane |
---|---|
Тема | Re: Commitfest Bug (was: Re: Reusing abbreviated keys during second pass of ordered [set] aggregates) |
Дата | |
Msg-id | 11179.1456846051@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Commitfest Bug (was: Re: Reusing abbreviated keys during second pass of ordered [set] aggregates) (Alvaro Herrera <alvherre@2ndquadrant.com>) |
Ответы |
Re: Commitfest Bug (was: Re: Reusing abbreviated keys
during second pass of ordered [set] aggregates)
Re: Commitfest Bug (was: Re: Reusing abbreviated keys during second pass of ordered [set] aggregates) |
Список | pgsql-hackers |
Alvaro Herrera <alvherre@2ndquadrant.com> writes: > Magnus Hagander wrote: >> 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. Definitely. > 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. +1 for not moving such patches to the new CF until the author does something --- at which point they'd change to "Needs Review" state. But we should not change them into that state without author input. And I don't see the value of having them in a new CF until the author does something. > I am even more unclear on "Rejected". My instinct says we should refuse > a move-to-next-cf for such patches. Right. Rejected is dead, it shouldn't propagate forward. regards, tom lane
В списке pgsql-hackers по дате отправления: