Re: Releasing in September

On 22 January 2016 at 16:34, Robert Haas <robertmhaas@gmail.com> wrote:

 

For my part, I am not sure the names in the release notes are actually
all that helpful.

It has one important effect of current interest: establishing the truth that multiple people and multiple companies are involved in producing and maintaining PostgreSQL. Whether the names are properly attributed will always be a time-consuming task, but I will oppose any attempt to remove or obscure evidence of who develops PostgreSQL, wherever that occurs.

Magnus Hagander <magnus@hagander.net> writes:
> On Jan 20, 2016 5:03 PM, "Andres Freund" <andres@anarazel.de> wrote:
>> FWIW, looking at the last few commitfests, aside heroic and
>> unsustainable efforts by individual CF managers, I haven't noticed any
>> effect of when fests started/stopped. Aside from a short time increase
>> in unfinished patches being posted the day before the next CFs starts.

> Yeah, we seem to be firmly stuck at two month long commitfests started
> every two months. The plan was for them to be one month..

> Maybe we should try just very drastically cutting them at one month and
> bumping everything left. No questions asked, no extra time for anybody.
> Regardless of if it's the first or the last commitfest.

> Just to see what happens. Because what we are doing now clearly doesn't
> work..

I do not think commitfest length is the problem (though surely it's not
working as intended).  What happened with 9.5 is we forked the 9.6

We will not get back to on-schedule releases unless we can keep -hackers
working on release testing/stabilization when it's time to do that,
rather than being distracted by shiny new stuff going into the next
release.

Joshua D. Drake wrote:

> 4. Submit a patch, review a patch.
>
> Don't review patches? Don't submit patches.

Here's one area where the commitfest app could help the CFM.  I would
like to have a report that shows, for each person, the list of patches
where they are author, and the list of patches where they are reviewer.
Then I can check his reviewer score by skimming a couple of threads and
say "you don't have enough author credits, go away".

On 2016-01-22 08:18:45 -0600, Jim Nasby wrote:
> Personally, I don't see why we have our scarcest resource doing what is
> essentially a project management task, especially when at least one
> commercial company has offered to donate paid staff time.

Because so far all CFs that weren't managed by somebody involved on the
code level worked even less than the rest. You need to be able to judge
how complex and ready a patch is to some degree. You need to know who to
prod for a specific patch.

Yes, a PM can learn to do that. But it's not something a freshly hired
person can do. You need a fair bit of community involvement.

Magnus Hagander <magnus@hagander.net> writes:
> On Wed, Jan 20, 2016 at 5:19 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> I do not think commitfest length is the problem (though surely it's not
>> working as intended).  What happened with 9.5 is we forked the 9.6

> I agree that it's not the same problem. I do believe that it is *a* problem
> though, and a fairly significant one too. Because there's *never* any
> downtime from CF mode, regardless of where in the cycle we are.

True, we've been failing badly on the intention that there would be time
off from CF mode, and I'd like to see a fix for that.  I do not think it's
directly related to the can't-get-a-release-out problem.

I'm not really sure why we've allowed CFs to drift on, though.  Can't we
just arbitrarily decree them closed on the last day of the month?  And
push unfinished work to the next one?  Admittedly, this probably doesn't
work for the last CF of a release cycle, but that one's always been a
special case.

Many people where happy with our consistent releasing major releases in
September, e.g. 9.0 to 9.3:

On Wed, Jan 20, 2016 at 10:48 AM, Andres Freund <andres@anarazel.de> wrote:
> On 2016-01-20 10:40:14 -0500, Bruce Momjian wrote:
>> We have gotten off of that cycle in the last two major releases, and
>> this isn't going to improve as long as we have commitfests starting
>> after January.
>
> I think this has very little to do with commitfest schedules, and much
> more with the "early" forking of the new version branch. For both 9.4
> and 9.5 we essentially spent a couple months twiddling our thumbs.

It's certainly true that we twiddled our thumbs quite a bit about
getting 9.5 ready to ship.  However, the old process where nobody
could get anything committed for six months out of the year blew
chunks, too.  Personally, I think that the solution is to cut off the
last CommitFest a lot sooner, and then reopen the tree for the next
release as soon as possible. 

But this never works, because there are
always patches we want to slip in late.

On Wed, Jan 20, 2016 at 06:58:24PM +0000, Simon Riggs wrote:
> The main problem is the length of the integration phase, which is mostly
> where nothing happens.

The open items wiki page saw steady change from 30 April to 28 December[1];
the two longest quiet periods were an eleven-day gap from 21 August and a
nine-day gap from 16 December.  Nineteen distinct contributors were finding,
fixing or otherwise editing data about 9.5 defects.  The integration work is
too slow, yes, but this persistent myth of a dead period is false.

For my part, I spent 1 July to 11 December reviewing 9.5 commits and reporting
or fixing defective 9.5 work.  (I did spoil myself with a few breaks fixing
pre-9.5 bugs.)  I doubt the 9.5 new bugs would have run dry within the next
five months, either, but the release team picked a fair juncture to give up
and call it dot-zero.

nm

[1] https://wiki.postgresql.org/index.php?title=PostgreSQL_9.5_Open_Items&limit=500&action=history

For my part, I am not sure the names in the release notes are actually
all that helpful.

On Wed, Jan 20, 2016 at 2:26 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> andres@anarazel.de (Andres Freund) writes:
>> On 2016-01-20 18:53:54 +0000, Simon Riggs wrote:
>>> What is the point in having a special mailing list to discuss the release
>>> schedule plus a face-to-face dev meeting to discuss this if we are going to
>>> discuss it here?
>
>> That list exists to discuss concrete releases, and is separate so we
>> e.g. can mention there's security issues and such. This topic in
>> contrast quite validly merits input from more then the usual suspects
>> going to a developer meeting.
>
> In particular, we have several important people who won't be in Brussels
> next week, so it's appropriate to hear their thoughts beforehand ...

As somebody who definitely won't be there, +1 from me.  :-)

On 01/20/2016 10:53 AM, Simon Riggs wrote:

On 20 January 2016 at 15:40, Bruce Momjian <bruce@momjian.us
<mailto:bruce@momjian.us>> wrote:

    Many people where happy with our consistent releasing major releases in
    September, e.g. 9.0 to 9.3:


What is the point in having a special mailing list to discuss the
release schedule plus a face-to-face dev meeting to discuss this if we
are going to discuss it here?

Because, like core although they (may) have the final word, taking solid feedback from people not on that committee or having that discussion publicly lends itself to:

 * Community
 * Transparency
 * The Open Source way

I think one thing we should work on, is being absolutely religious about
requiring, say, 2 reviews for every nontrivial contribution.  We
currently seem to have a significantly increased submission rate, and at
the same time the number of reviews per patch has gone down
substantially.  I think the "honor" system has failed in that regard.

Robert Haas <robertmhaas@gmail.com> writes:
> But I'm not very sure that we're talking about the same set of people
> here.  If we're going to go to a system where nobody's allowed to
> commit anything for the next release until the current release is
> finalized, then we'd better have some procedure for making sure that
> happens relatively quickly.  And the procedure can't be that the
> people who are hot to get started on the next release have to bat
> cleanup for the people who don't have time to fix the bugs they
> introduced previously.  Because *that* would be manifestly unfair.

You're assuming that the people who are hot to get started on the next
release are different from the people who don't have time to fix the bugs
they introduced previously.  IME it's mostly the same people.

Many people were happy with our consistent releasing major releases in
September, e.g. 9.0 to 9.3:

        9.5   2016-01-07
        9.4   2014-12-18
        9.3   2013-09-09 <--
        9.2   2012-09-10 <--
        9.1   2011-09-12 <--
        9.0   2010-09-20 <--
        8.4   2009-07-01
        8.3   2008-02-04
        8.2   2006-12-05
        8.1   2005-11-08
        8.0   2005-01-19

We have gotten off of that cycle in the last two major releases

For 9.6 we have a commitfest starting in March 1.  This will
never allow a September release.

Our current 9.5/9.6 timing looks more like the 8.X series of release
dates.  Everyone might be fine with that, but we had better be prepared
for November-February major release dates going forward.

Many people where happy with our consistent releasing major releases in
September, e.g. 9.0 to 9.3: