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?
Re: How do we track backpatches? |
Список | 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 по дате отправления: