Re: How do we track backpatches?

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?

In response to

Responses

Browse pgsql-hackers by date

  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