From: | Peter Eisentraut <peter_e(at)gmx(dot)net> |
---|---|
To: | Magnus Hagander <magnus(at)hagander(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 02:44:53 |
Message-ID: | 1371609893.13762.18.camel@vanquo.pezone.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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.
> But since those
> patches are typically going into HEAD as well, why not just a
> commitfest *topic* for it, on whatever commitfest happens to be the
> open one? Then it'll get processed within the existing workflow.
But then how do you represent that the actual commit fest is closed, and
how do you, well, actually track the patches that need to be
backpatched?
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Eisentraut | 2013-06-19 02:48:11 | Re: Bugfix and new feature for PGXS |
Previous Message | Etsuro Fujita | 2013-06-19 02:35:21 | Re: Patch for removng unused targets |