Re: Releasing in September - Mailing list pgsql-hackers

On Thu, Jan 21, 2016 at 10:11 AM, Michael Paquier <michael.paquier@gmail.com> wrote:
>
> On Thu, Jan 21, 2016 at 1:32 PM, Michael Paquier
> <michael.paquier@gmail.com> wrote:
> > On Thu, Jan 21, 2016 at 12:59 AM, Bruce Momjian <bruce@momjian.us> wrote:
> >> On Wed, Jan 20, 2016 at 10:55:07AM -0500, Robert Haas wrote:
> >>> On Wed, Jan 20, 2016 at 10:48 AM, Andres Freund <andres@anarazel.de> wrote:
> >>> > 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.
> >>
> >> The bottom line is we can't sustain five commitfests and stay on time
> >> --- we need to go back to four, which I think is what we used to do.  We
> >> twiddled our thumbs back in the September-release years too, but had
> >> consistency because twiddling was built into the schedule.
> >
> > Here I agree. Five commit fests is proving to be a lot and CF managers
> > are facing a severe burnout. Though I guess it sounded like a fine
> > idea at the moment this was begun (disclaimer: I was not there). So we
> > may want to do back to 4, and avoid too much overlapping between CFs
> > and what would be a stability period, without any commit fests going
> > on. It seems to me that the problem regarding the fact that fixes got
> > committed late is that committer's, author's and reviewer's attention
> > are getting distracted with commit fests and the new features proposed
> > there. Perhaps some people are more interested in implementing new
> > features than working on bugs and would just continue hacking and
> > arguing about new features, at least a stability period may attract
> > more committer attention into actual bug fixes, in short: no new
> > features can be committed until the previous versions has reached at
> > least beta2, rc, whatever. This may accelerate the stability process.
>
> Another idea popping to my mind in order to fix the CF manager burnout
> and actually motivate people into becoming CF managers: say that one a
> CF manager is done with a commit fest, folks on -hackers discuss if
> the CFM has done a good job or not. If yes, he gets a travel paid to
> the conference of his choice.

>