Re: 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(at)gmx(dot)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/

On 2013-06-18 12:32:42 +0200, Magnus Hagander wrote:
> On Tue, Jun 18, 2013 at 4:48 AM, Peter Eisentraut <peter_e(at)gmx(dot)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(at)gmx(dot)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/

> 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(at)2ndquadrant(dot)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/