Re: commitfest 2018-07

From: Ashutosh Bapat <ashutosh(dot)bapat(at)enterprisedb(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Michael Paquier <michael(at)paquier(dot)xyz>, Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: commitfest 2018-07
Date: 2018-06-05 12:23:36
Message-ID: CAFjFpRcyd1+6q4WTiSkW7dS-BGRv8SdJapY36KOef-D5mP8-hw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, Jun 5, 2018 at 9:02 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Michael Paquier <michael(at)paquier(dot)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.

[1] https://wiki.postgresql.org/wiki/PgCon_2018_Developer_Meeting

--
Best Wishes,
Ashutosh Bapat
EnterpriseDB Corporation
The Postgres Database Company

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2018-06-05 12:42:30 Re: Spilling hashed SetOps and aggregates to disk
Previous Message Teodor Sigaev 2018-06-05 12:20:35 Re: \d t: ERROR: XX000: cache lookup failed for relation