On 2015-05-19 09:43:54 -0700, Joshua D. Drake wrote: > > On 05/18/2015 08:52 PM, Andres Freund wrote: > > >Maybe we should forget them and just have monthly 'judgefests' where > >some poor sod summarizes the current state and direction, and we then > >collaboratively discuss whether we see things going anywhere and if not, > >what would need to happen that they do. And have a policy that "older" > >patches should be preferred over newer ones; but at the same time cull > >patches continually sitting at the tail end as 'not interesting'. > > > > I don't think this will be a productive solution. I would argue that any > solution we come up with, somebody is going to think they got the short end > of the stick. There will be someone that thinks it is inefficient, that it > doesn't suit their needs or that it doesn't work in their paradigm. That is > why we don't have a proper issue/bug tracker. That is why we are constantly > "inventing here" instead of relying on the work of others (when it comes to > this particular problem).
What does that have to do with the suggestion above? That seems entirely unrelated to changing CFs to a different format. > I don't know what the solution is but I know I like the idea of a tree > freeze except for bug fixes for at least 3 weeks but I would be jumping for > joy if we froze the tree except for bug fixes for 6 or 12 weeks. We've done that for pretty much every release so far? > I don't care about 9.6 at this point. But you don't develop things for it, so you're in a very different position. It takes a *lot* of time to come up with a serious proposal for a new feature, and then lots more time to come up with a reasonable patch. To get a serious feature into 9.6 you pretty much have to already have started by now. > We move so fast anyway, most people I know haven't even migrated to > 9.4.x and even more are happily plugging away on 9.2. I don't think that's really related to moving fast. It's just that existing systems don't necessarily need to move - after all they could put the system into production at their respective version. That's different to when you consider adopting/extending postgres for a new use case/product. And there people quit regularly lament a couple problems in postgres. Say if we, and there's been serious talk about that, addressed vacuuming being so painful, that'd certainly increase adoption in the mid term. Greetings, Andres Freund -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers