Re: Last gasp - Mailing list pgsql-hackers
From | Tom Lane |
---|---|
Subject | Re: Last gasp |
Date | |
Msg-id | 8687.1333833601@sss.pgh.pa.us Whole thread Raw |
In response to | Re: Last gasp (Robert Haas <robertmhaas@gmail.com>) |
Responses |
Re: Last gasp
Re: Last gasp Re: Last gasp Re: Last gasp |
List | pgsql-hackers |
Robert Haas <robertmhaas@gmail.com> writes: > [ among other good points ] > ... On a related note, letting CommitFests go on for three > months because there's insufficient reviewer activity to get them done > in one or two is, in my opinion, not much of a solution. If there's > even less reviewer activity next time, are we going to let it go on > for four months? Six months? Twelve months? At some point, it boils > down to "we're just going to stop accepting patches for an indefinite > period of time". Yuck. Yeah, this is something I was thinking about yesterday. In the first couple of release cycles with the CommitFest process, we were willing to let the last fest of a release cycle go on for "as long as it takes", or at least that was what I felt the policy to be. This time we eventually gave up and declared closure, but in hindsight we should likely have done that a month earlier. The fact of the matter is that quite a few of the patches we were dealing with were *not* ready to commit, or even close to that, at the start of the fest. If it weren't the last fest they would have gotten marked Returned With Feedback a lot sooner. I wonder whether we ought to have a preset schedule for last fests just like the others. I'd be willing to let them run, say, 2 months instead of 1, but no deadline at all risks turning the whole affair into a death march, which is no fun for anybody and threatens the quality of the end result too. There's too much temptation to commit patches that are not really ready, just to get them out of the way. In short, the idea of strongly calendar-driven releases looks more and more attractive to me the more times we go through this process. If your patch isn't ready on date X, then it's not getting into this release; but there'll be another bus coming along before long. Stretching out release cycles to get in those last few neat features just increases the pressure for more of the same, because people don't know how long it will be to the next release. regards, tom lane
pgsql-hackers by date: