Re: Releasing in September - Mailing list pgsql-hackers

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
developmentrelease.
 

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