Re: a few thoughts on the schedule

On 2015-05-19 10:25:49 -0400, Robert Haas wrote:
> On Mon, May 18, 2015 at 11:52 PM, Andres Freund <andres@anarazel.de> wrote:
> > 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.

Ah, ok.

> The vary earliest time frame that would make sense to me is to branch
> July 1st and start a CF on July 15th.

I'm wondering why the CF has to start after branching? Or is that just
two independent dates? The first week or so of the first CF won't have
much stuff ready for commit.

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

Why? To me the last few beta periods were pretty drawn out affairs,
without much happening. Yes, there was the jsonb stuff in 9.4 delaying
the release, but that wasn't waiting for work, but a decision.  But most
of the time everyone was developing their stuff for the next cycle,
waiting for beta testers to come forward with bugs. Not very much of
that happened.

I think a shorter schedule might actually help us to both, get the open
issues closed sooner, and get more actual testing. Most people seem to
work with a "Oh, there's time left, I can do that later" attitude.

I mean if there'd actually be lots of people busy testing, sure, a long
beta makes sense for postgres (complex, contains critical data). But I
don't think that's happening.

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

I tend to agree that Dec 15 is a bad idea.

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

Agreed.  I think right now to succeed in the project you need to be
extraordinarily stubborn or patient. Which in turn comes with its own
set of problems in the long term, besides lower participation. The set
of qualities needed to succeed aren't the same that I see needed in the
project.

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

Agreed, that we can't just demand it. But I think without changing
anything the situation will just get worse and worse, because there'll
be few new senior people.

I think part of that is saying "no" more efficiently, upfront. Which is
why I really want the triage step.
a) It's much better for the project to not have several "junior" reviewers  first spend time on a patch, then have a
smallflamefest, and then  have somebody "senior" reject a patch in its entirety. That's a waste  of everyone's effort
andfrustrating.
 
b) It's not that bad to hear a "no" as a new contributor soon after  submission. It's something entirely different to
gothrough a long  bikeshedding, several revisions of reworking, just to be told in the  end that it was a bad idea from
theget go.
 

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

I'm not sure. ISTM that a painfull couple hours every now and then are
much less bad than the continuous CF we had lately. I personally also
find it frustrating to go through the CF and see a good portion of
things that I never can see going anywhere, but that still suck up
resources.

I'd actually be willing to do triage every now and then; but I don't
think it should always be the same person. For one it does come with
power, for another it's nice to now always be the person having to tell
people that their stuff isn't relevant/good/whatever enough. It's also
not good to needlessly build up SPOFs.

> Unless talented reviewers can get such job offers, we are going to
> continue to have trouble making ends meet.

Hasn't every talented reviewer gotten job offers shortly afterwards in
the last few years?  The ones that accept don't necessarily work that
much in the community, but several seem to. And I think in the case of
several people the reason they don't, is less the company, but that it's
emotionally draining.

Greetings,

Andres Freund