Re: [HACKERS] How do we track backpatches?

2013-06-19 Thread Magnus Hagander
On Wed, Jun 19, 2013 at 4:44 AM, Peter Eisentraut pete...@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


Re: [HACKERS] How do we track backpatches?

2013-06-19 Thread Josh Berkus

 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


Re: [HACKERS] How do we track backpatches?

2013-06-19 Thread Magnus Hagander
On Wed, Jun 19, 2013 at 8:54 PM, Alvaro Herrera
alvhe...@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


Re: [HACKERS] How do we track backpatches?

2013-06-19 Thread Alvaro Herrera
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 Herrerahttp://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


Re: [HACKERS] How do we track backpatches?

2013-06-18 Thread Cédric Villemain
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


signature.asc
Description: This is a digitally signed message part.


Re: [HACKERS] How do we track backpatches?

2013-06-18 Thread Magnus Hagander
On Tue, Jun 18, 2013 at 4:48 AM, Peter Eisentraut pete...@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


Re: [HACKERS] How do we track backpatches?

2013-06-18 Thread Andres Freund
On 2013-06-18 12:32:42 +0200, Magnus Hagander wrote:
 On Tue, Jun 18, 2013 at 4:48 AM, Peter Eisentraut pete...@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


Re: [HACKERS] How do we track backpatches?

2013-06-18 Thread Peter Eisentraut
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


Re: [HACKERS] How do we track backpatches?

2013-06-18 Thread Noah Misch
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


[HACKERS] How do we track backpatches?

2013-06-17 Thread Josh Berkus
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?

-- 
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


Re: [HACKERS] How do we track backpatches?

2013-06-17 Thread Peter Eisentraut
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