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
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 |