Re: How do we track backpatches?

Поиск
Список
Период
Сортировка
От Peter Eisentraut
Тема Re: How do we track backpatches?
Дата
Msg-id 1371609893.13762.18.camel@vanquo.pezone.net
обсуждение исходный текст
Ответ на Re: How do we track backpatches?  (Magnus Hagander <magnus@hagander.net>)
Ответы Re: How do we track backpatches?  (Noah Misch <noah@leadboat.com>)
Re: How do we track backpatches?  (Magnus Hagander <magnus@hagander.net>)
Список 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?




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

Предыдущее
От: Jim Nasby
Дата:
Сообщение: Re: Vacuum, Freeze and Analyze: the big picture
Следующее
От: Peter Eisentraut
Дата:
Сообщение: Re: Bugfix and new feature for PGXS