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