Re: How do we track backpatches?
От | Andres Freund |
---|---|
Тема | Re: How do we track backpatches? |
Дата | |
Msg-id | 20130618103720.GE5646@awork2.anarazel.de обсуждение исходный текст |
Ответ на | Re: How do we track backpatches? (Magnus Hagander <magnus@hagander.net>) |
Список | pgsql-hackers |
On 2013-06-18 12:32:42 +0200, Magnus Hagander wrote: > 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. 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
В списке pgsql-hackers по дате отправления: