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

On Tue, May 19, 2015 at 1:35 PM, Andres Freund <andres@anarazel.de> wrote:
>> 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.

Well, if there is something ready to commit, I'd like to be able to commit it.

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

There's something to that theory.  I'm just worried all of those last
minute commits are hiding a bunch of bugs.

> 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 small flamefest, and then
>    have somebody "senior" reject a patch in its entirety. That's a waste
>    of everyone's effort and frustrating.
> b) It's not that bad to hear a "no" as a new contributor soon after
>    submission. It's something entirely different to go through a long
>    bikeshedding, several revisions of reworking, just to be told in the
>    end that it was a bad idea from the get go.

I agree this would help.  Figuring out how to do it in a reasonable
way would help a lot.  If we could get say 4 committers to go through
at the start of each CommitFest and each comment very briefly on 25%
of the patches each (yes, no, or maybe, and a bit of justification), I
bet that would streamline things considerably.  If we could get each
committer to go through 50% of the patches and do this, then each
patch would get a quick opinion from two committers right at the
outset.  That would be even nicer.

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

Agreed, lots of people get job offers.  But somehow we're still short
of reviewers, so something's not working the way it needs to.  Maybe
that's for the reason you postulate, or maybe it's for the reason I
postulate, or maybe there is some other reason.

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