Re: a few thoughts on the schedule - Mailing list pgsql-hackers

On Mon, May 18, 2015 at 11:52 PM, Andres Freund <andres@anarazel.de> wrote:
>> > [first 9.6 CF around 2015-07-15]
>
>> Honestly, that seems awful soon.  I would have thought maybe August 15th.
>
> Maybe we should just rename it to 9.6-1 for now? And then look how
> things look around pgcon?

I'd rather agree on a date.  People need to plan their schedules.

>> I am inclined to think the 5-CommitFest thing we did this time did not
>> work out. It might've been fine if feature freeze had been a month
>> earlier, but by freezing in May we've pretty clearly stolen at least a
>> month, if not two, from the next cycle.
>
> I personally think the late close of the 9.4 cycle has alone thrings far
> enough off track that we can't fairly evaluate a 5 CF schedule.

Oh, I agree with that.  I'm certainly not saying we shouldn't do it
again.  But I don't see a practical way to do 5 CFs again for 9.6 and
also release it in September of 2016.  I don't think it would be a
good idea to open the tree for 9.6 development in three weeks, or even
in time for a July 1st CommitFest.  The vary earliest time frame that
would make sense to me is to branch July 1st and start a CF on July
15th.  If we schedule four more CommitFests after that at two month
intervals, they would start on September 15th, November 15th, January
15th, and March 15th, putting us a month behind where we were this
time.  That's not going to work.

So I think the options are:

- Do 4 CommitFests as we have for past releases.  We could do July
15th, September 15th, November 15th, and January 15th; or we could do
August 1st, October 1st, December 1st, and February 1st; or we could
do August 15th, October 15th, December 15th, and February 15th.
Probably, that last one isn't so good: starting on December 15th is
going to suck.

- Do 5 or more CommitFests and accept that the release cycle is going
to be more than a year.  Personally, given where we're at right now, I
don't think an early fall release of 9.5 is going to be remotely
practical.  I think we're going to end up releasing in late fall or
early in the new year.  So I'd be completely fine with a schedule that
aims for 9.6 to get released around March-May of 2017, so the last
CommitFest would start in August or September of 2016.  I expect that
to be unpopular, which is fine, but then I think we have to limit
ourselves to 4 CFs this time through.

> Personally I'm coming more and more to the conclusion that CFs just
> don't work [anymore]. I think the *tracking* itself is rather important
> and has a worthwhile role. But it seems to me that what CFs have lately
> essentially ended up being, is closer to a cycle long review queue than
> anything else.

I mostly agree with that.

> ISTM that the CF scheduling right now does more harm than good.
> * They seem to frustrate a lot of the people doing a lot of
>   reviews.
> * Evidently they don't very well prevent individual patches from
>   just slipping through and through.
> * They lead to completely uninteresting patches being reviewed before
> others.
> * The contribution experience is still pretty painful and takes ages

Those are legitimate issues.

> 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 think we need to start by understanding that we need the
contribution experience to be good for both patch authors and also for
reviewers (including reviewers who are commiters).   We very much need
to give new contributors a good experience of submitting patches and
getting useful feedback and getting stuff committed.  I think it's
clear that we could do a much better job at that, and the project
would benefit enormously.  However, doing a better job means spending
more time on it, and we can't just demand that senior reviewers or
contributors spend more time on it.  I mean, we can, I guess, but it
will only breed frustration and resentment.  I'm not sure what the
solution is here, but if it boils down to telling people who have put
a lot of effort into the project over a long period of time that they
are not doing enough, I'm here to say that won't work.

So one problem that comes up in the context of your proposal is that
it's likely to be hard to find the "poor sod" whose existence you
hypothecate.  Maybe there is someone who will do that once or twice,
but I think it'll be hard to keep that position filled over the long
term.

Unfortunately, I don't have a lot of good ideas here.  I know that I
spend as much time reviewing other people's patches as I can manage to
find in my schedule, and I know a lot of people would probably like to
see me do more of that.  I'm sure there are also some people who would
like to see me do less of that, and at least a few who would like to
see me die in a fire.  Ultimately, this is about money.  I have a job
where I can devote some time to reviewing other people's patches,
which is great: many people aren't that lucky.  Nobody has offered me
a job where I can spend a higher percentage of my time doing that than
I spend now.  Unless talented reviewers can get such job offers, we
are going to continue to have trouble making ends meet.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company