Greetings,
* Ashutosh Bapat (ashutosh.bapat@enterprisedb.com) wrote:
> On Tue, Jun 5, 2018 at 9:02 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> > Michael Paquier <michael@paquier.xyz> writes:
> >> On Mon, Jun 04, 2018 at 07:16:33PM -0400, Peter Eisentraut wrote:
> >>> There were some discussions about renaming the existing 2018-09 entry
> >>> versus inserting a new one at -07 and requiring patches to be moved back
> >>> explicitly.
> >
> >> I would do that to reduce unnecessary log noise, but I was unsure of the
> >> actual status we are at. I am pretty sure that nobody is going to
> >> complain if what they submitted gets looked up two months earlier than
> >> what was previously planned, so I would vote to rename the existing
> >> 2018-09 to 2018-07, to rename the existing 2018-11 to 2018-09, and to
> >> create three new CF entries.
> >
> > +1 for just renaming 2018-09 to 2018-07, if we can do that. We'll end
> > up postponing some entries back to -09, but that seems like less churn
> > than the other way.
>
> Notes at [1] about keeping this commitfest for small patches. Just
> renaming the commitfest would mean all the patches, big and small, can
> be reviewed and committed.
"Yes and no."
While there were concerns raised that larger patches committed earlier
might cause back-patching issues, the general consensus from my read of
it was that it wasn't likely to be that big of an issue. While I
suspect we'll still generally focus on getting smaller changes in during
the 2018-07 cycle, to try and "clear the way" for the larger patches,
I'm no longer concerned about larger patches which are ready being
committed during that cycle.
As such, I'm also +1 on the proposal to rename 2018-09 to 2018-07, and
make the other renames and add a new one to the end.
> [1] https://wiki.postgresql.org/wiki/PgCon_2018_Developer_Meeting
Thanks!
Stephen