Hi, On 2016-01-26 00:26:18 -0600, Joshua Berkus wrote: > Let's do quarterly development releases and supported production > releases every 18 months.
> A 3-month release cycle would let people see their code go into the wild a > lot faster; basically we'd do a CF then a development release. There are reason for/against doing that, but why would it actually change the problem significantly? It won't change the amount of necessary review, debugging and bugfixing by a very significant amount. One CF / 3 months might actually make it harder to get a patch into a revieawable state, because the time-to-feedback is larger. > The alternative to this is an aggressive recruitment and mentorship > program to create more major contributors who can do deep review of > patches. But that doesn't seem to have happened in the last 5 years, > and even if we started it now, it would be 2 years before it paid off. I think the amount of review and maintenance time is the largest part of the problem here, and is mostly unaffected by the manner we actually schedule releases. The discussions around dropping patches on the floor are partially a question of that, and partially a question of not acceppting to maintain things that are of low interest. But I don't really see "aggressive recruitment and mentorship" really fixing this, even though there are other good reasons to work more on that side. I think more fundamentally the issue is that that doing a "deep" review of a bigger patches takes so much time and knowledge, that it's not realistic to do so in ones own time anymore. You can if you're very dedicated over a long time, but realistically in most cases it requires your employer having an interest in you doing that. Quite obviously there's an increasing number of employers paying people to submit things to postgres, whereas there seems no corresponding uptick on the review side. Unless the "paying people to do review side" is solved (which has a *long* lead time), I don't see more recruiting, different CF schedules, or anything like that really fixing the critical bottlenecks. Reducing the amount of work, i.e. dropping patches not interesting or too complex, seems to be the only solution until then. As a short aside: I think another side of the coin is that, if you're dedicated to work on a cool open source project, these days you'll find a paying open source job so quickly, that a lot of people that would have worked on e.g. postgres in their evenings, now just hack something they're paid both during the day and the evening. Andres -- Sent via pgsql-hackers mailing list (email@example.com) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers