Обсуждение: How do we track backpatches?
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
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.
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 HaganderMe: http://www.hagander.net/Work: http://www.redpill-linpro.com/
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
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?
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
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 HaganderMe: http://www.hagander.net/Work: http://www.redpill-linpro.com/
> 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
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
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 HaganderMe: http://www.hagander.net/Work: http://www.redpill-linpro.com/