Re: Releasing in September

On Thu, Jan 21, 2016 at 10:11 AM, Michael Paquier <michael(dot)paquier(at)gmail(dot)com>
wrote:
>
> On Thu, Jan 21, 2016 at 1:32 PM, Michael Paquier
> <michael(dot)paquier(at)gmail(dot)com> wrote:
> > On Thu, Jan 21, 2016 at 12:59 AM, Bruce Momjian <bruce(at)momjian(dot)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(at)anarazel(dot)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.
>

I also think there should be some way to give credit to CFM, if it is
difficult to do anything related to money, then we can enforce that if
CFM submits any patches for next CF, then those should be prioritised.

With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com