From: | Magnus Hagander <magnus(at)hagander(dot)net> |
---|---|
To: | Peter Eisentraut <peter_e(at)gmx(dot)net> |
Cc: | Josh Berkus <josh(at)agliodbs(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: How do we track backpatches? |
Date: | 2013-06-19 07:00:59 |
Message-ID: | CABUevEwpQjQg0tEVXqdzJU3=WHFctR9UMWm=Uxbm8NK5En81Cw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Wed, Jun 19, 2013 at 4:44 AM, Peter Eisentraut <peter_e(at)gmx(dot)net> wrote:
> On Tue, 2013-06-18 at 12:32 +0200, Magnus Hagander wrote:
>> The CF app was and is specifically for dealing with CFs. Having it
>> deal with backpatches makes it, well, a bugtracker. It's not meant to
>> be that. If we want a bugtracker, then it has very different
>> requirements.
>
> It's not in evidence that the requirements are different. The CF app is
> basically a list of lists of patches with date information and
> associated person's names. Tracking backpatch candidates doesn't sound
> that much different. (That said, I'm not convinced backpatches need any
> tracking at all, but if they did, I think the CF app would be just
> fine.)
>>
>> Having an always-open CF would defeat the workflow.
>
> I'd imagine having a "CF" entry per release, so after a set of minor
> releases, the "CF" is closed.
Oh, I think I misunderstood what you meant.
That way does make a lot more sense than what I thought you were
saying :) I shall withdraw my objection.
--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/
From | Date | Subject | |
---|---|---|---|
Next Message | Hitoshi Harada | 2013-06-19 07:15:56 | Re: extensible external toast tuple support & snappy prototype |
Previous Message | Heikki Linnakangas | 2013-06-19 06:28:33 | Re: XLogInsert scaling, revisited |