Re: How do we track backpatches? - Mailing list pgsql-hackers

From Peter Eisentraut
Subject Re: How do we track backpatches?
Date
Msg-id 1371609893.13762.18.camel@vanquo.pezone.net
Whole thread Raw
In response to Re: How do we track backpatches?  (Magnus Hagander <magnus@hagander.net>)
Responses Re: How do we track backpatches?
Re: How do we track backpatches?
List 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?




pgsql-hackers by date:

Previous
From: Jim Nasby
Date:
Subject: Re: Vacuum, Freeze and Analyze: the big picture
Next
From: Peter Eisentraut
Date:
Subject: Re: Bugfix and new feature for PGXS