Re: How do we track backpatches?

Поиск
Список
Период
Сортировка
От Magnus Hagander
Тема Re: How do we track backpatches?
Дата
Msg-id CABUevEybuLgtJkyduOgtZeGZP_NE90d7-Q2qZU_NxsEr0q+DaA@mail.gmail.com
обсуждение исходный текст
Ответ на Re: How do we track backpatches?  (Peter Eisentraut <peter_e@gmx.net>)
Ответы Re: How do we track backpatches?  (Andres Freund <andres@2ndquadrant.com>)
Re: How do we track backpatches?  (Peter Eisentraut <peter_e@gmx.net>)
Список pgsql-hackers
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/



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Cédric Villemain
Дата:
Сообщение: Re: How do we track backpatches?
Следующее
От: Dean Rasheed
Дата:
Сообщение: Review: UNNEST (and other functions) WITH ORDINALITY