Re: "rejected" vs "returned with feedback" in new CF app
| От | Magnus Hagander |
|---|---|
| Тема | Re: "rejected" vs "returned with feedback" in new CF app |
| Дата | |
| Msg-id | CABUevExi47r=pbX3DUQkLYFwhwsiLGuTzPL7uLTMhgjJXFiJaQ@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: "rejected" vs "returned with feedback" in new CF app (Tom Lane <tgl@sss.pgh.pa.us>) |
| Ответы |
Re: "rejected" vs "returned with feedback" in new CF app
(Andres Freund <andres@anarazel.de>)
Re: "rejected" vs "returned with feedback" in new CF app (Alvaro Herrera <alvherre@2ndquadrant.com>) Re: "rejected" vs "returned with feedback" in new CF app (Andrew Dunstan <andrew@dunslane.net>) Re: "rejected" vs "returned with feedback" in new CF app ("David G. Johnston" <david.g.johnston@gmail.com>) |
| Список | pgsql-hackers |
On Thu, Apr 9, 2015 at 2:20 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Magnus Hagander <magnus@hagander.net> writes:
> On Apr 9, 2015 2:20 AM, "Robert Haas" <robertmhaas@gmail.com> wrote:
>> +1.
> Is that at +1 for naming it moved, or for not having it? :-)
> I can definitely go with moved. Buy I would like to keep it - the reason
> for having it in the first place is to make the history of the patch follow
> along when it goes to the next cf. If we don't have the move option, I
> think it's likely that we'll be back to the same patch having multiple
> completely unrelated entries in different cfs.
The problem with the whole thing is that you're asking the person doing
the "returned" marking to guess whether the patch will be resubmitted in
a future CF.
The right workflow here, IMO, is that a patch should be marked returned or
rejected, full stop; and then when/if the author submits a new version for
a future CF, there should be a way *at that time* to re-link the email
thread into that future CF.
If we just link the email thread, that would mean we loose all those precious annotations we just added support for. Is that really what you meant? We also loose all history of a patch, and can't see that a previous version existed in a previous commitfest, without manually checking each and every one. But if that's a history we don't *want*, that's of course doable, but it seems wrong to me?
I'm not necessarily saying that what we have now is right, but just giving up on the history completely doesn't seem like a very good workflow to me.
We could always tell those people to "go back and find your old patch and re-open it", but in fairness, are people likely to actually do that?
"Moved" is really only applicable, I think, for cases where we punt a
patch to the next CF for lack of time.
Well, that's basically what "returned with feedback" is now, so I guess that one should just be renamed in that case. And we add a new "returned with feedback" that closes out the patch and doesn't move it anywhere. Which is pretty similar to the suggestion earlier in this thread except it also swaps the two names.
В списке pgsql-hackers по дате отправления:
Следующее
От: Craig RingerДата:
Сообщение: Re: pg_restore -t should match views, matviews, and foreign tables