How do we track backpatches?

On Mon, 2013-06-17 at 17:11 -0700, Josh Berkus wrote:

Contributors,

While going through this mailing list looking for missing 9.4 patches, I
realized that we don't track backpatches (that is, fixes to prior
versions) at all anywhere. Where backpatches are submitted by
committers this isn't an issue, but we had a couple major ones (like the
autovacuum fix) which were submitted by general contributors. The same
goes for beta fixes.

Should we add a "prior version" category to the CF to make sure these
don't get dropped? Or do something else?

A separate commit fest for tracking proposed backpatches might be
useful.

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Le mardi 18 juin 2013 04:48:02, Peter Eisentraut a écrit :

On Mon, 2013-06-17 at 17:11 -0700, Josh Berkus wrote:

Contributors,

While going through this mailing list looking for missing 9.4 patches, I
realized that we don't track backpatches (that is, fixes to prior
versions) at all anywhere. Where backpatches are submitted by
committers this isn't an issue, but we had a couple major ones (like the
autovacuum fix) which were submitted by general contributors. The same
goes for beta fixes.

Should we add a "prior version" category to the CF to make sure these
don't get dropped? Or do something else?

A separate commit fest for tracking proposed backpatches might be
useful.

Backpatches are bugs fix, isnt it ?

I will like to have a mail based bug tracker like debbugs.
--
Cédric Villemain +33 (0)6 20 30 22 52
http://2ndQuadrant.fr/
PostgreSQL: Support 24x7 - Développement, Expertise et Formation

On Tue, Jun 18, 2013 at 4:48 AM, Peter Eisentraut <peter_e@gmx.net> wrote:

On Mon, 2013-06-17 at 17:11 -0700, Josh Berkus wrote:

Contributors,

While going through this mailing list looking for missing 9.4 patches, I
realized that we don't track backpatches (that is, fixes to prior
versions) at all anywhere. Where backpatches are submitted by
committers this isn't an issue, but we had a couple major ones (like the
autovacuum fix) which were submitted by general contributors. The same
goes for beta fixes.

Should we add a "prior version" category to the CF to make sure these
don't get dropped? Or do something else?

A separate commit fest for tracking proposed backpatches might be
useful.

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.

Having an always-open CF would defeat the workflow. 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.

--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

On 2013-06-18 12:32:42 +0200, Magnus Hagander wrote:

On Tue, Jun 18, 2013 at 4:48 AM, Peter Eisentraut <peter_e@gmx.net> wrote:

On Mon, 2013-06-17 at 17:11 -0700, Josh Berkus wrote:

Contributors,

While going through this mailing list looking for missing 9.4 patches, I
realized that we don't track backpatches (that is, fixes to prior
versions) at all anywhere. Where backpatches are submitted by
committers this isn't an issue, but we had a couple major ones (like the
autovacuum fix) which were submitted by general contributors. The same
goes for beta fixes.

Should we add a "prior version" category to the CF to make sure these
don't get dropped? Or do something else?

A separate commit fest for tracking proposed backpatches might be
useful.

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.

Having an always-open CF would defeat the workflow. 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.

The schedules for a CF and a minor release don't really line up though,
so I am not sure if that ends up being much better than not tracking
them there...

Greetings,

Andres Freund

--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/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?

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

On Tue, Jun 18, 2013 at 10:44:53PM -0400, Peter Eisentraut 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.)

Agreed; bug fixes to be back-patched have appeared in most CFs, and I think
the CF process and app have served them fine.

--
Noah Misch
EnterpriseDB http://www.enterprisedb.com

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

On Wed, Jun 19, 2013 at 4:44 AM, Peter Eisentraut <peter_e@gmx.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/

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

I'd imagine having a "CF" entry per release, so after a set of minor
releases, the "CF" is closed.

How would we name these?

Also, what about patches for beta? Should we have a "beta" CF?

--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Josh Berkus wrote:

I'd imagine having a "CF" entry per release, so after a set of minor
releases, the "CF" is closed.

How would we name these?

Also, what about patches for beta? Should we have a "beta" CF?

Don't we have the Open Items wiki page for those? Seems to work well
enough.

--
�lvaro Herrera http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

On Wed, Jun 19, 2013 at 8:54 PM, Alvaro Herrera
<alvherre@2ndquadrant.com> wrote:

Josh Berkus wrote:

I'd imagine having a "CF" entry per release, so after a set of minor
releases, the "CF" is closed.

How would we name these?

Also, what about patches for beta? Should we have a "beta" CF?

Don't we have the Open Items wiki page for those? Seems to work well
enough.

Yes. The CF app only tracks things that already have patches. For the
beta, we really need to track things that may not have been fixed - or
that may have been done, just only partially so far.

--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers