| From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | Magnus Hagander <magnus(at)hagander(dot)net>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, Peter Eisentraut <peter_e(at)gmx(dot)net>, Andres Freund <andres(at)anarazel(dot)de> |
| Subject: | Re: "rejected" vs "returned with feedback" in new CF app |
| Date: | 2015-04-10 02:23:30 |
| Message-ID: | 71EDE632-3816-4A81-A3EF-4CF642B2445B@gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Apr 9, 2015, at 5:50 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> 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.
Yeah, or a way to reactivate the old entry at that time. Any kind of routine carryover to the next CF is going to lead to an accumulation of dead patches with live CF entries; it should require some action to re-enter a previously returned patch in the latest CF.
...Robert
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Robert Haas | 2015-04-10 02:29:52 | Re: NOT NULL markings for BKI columns |
| Previous Message | Robert Haas | 2015-04-10 02:17:20 | Re: FPW compression leaks information |