From: | Ibrar Ahmed <ibrar(dot)ahmed(at)percona(dot)com> |
---|---|
To: | Julien Rouhaud <rjuju123(at)gmail(dot)com> |
Cc: | Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: [Commitfest 2022-09] Date is Over. |
Date: | 2022-10-06 16:00:02 |
Message-ID: | CALcuYDLUwPSnik0JjmdgRXP34cBQFdVocDj-Z3p9-cjXj_Smag@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Wed, Oct 5, 2022 at 3:01 PM Julien Rouhaud <rjuju123(at)gmail(dot)com> wrote:
> Hi,
>
> On Wed, Oct 05, 2022 at 02:50:58PM +0500, Ibrar Ahmed wrote:
> > On Wed, 5 Oct 2022 at 1:43 PM, Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>
> > wrote:
> >
> > > On 2022-Oct-03, Ibrar Ahmed wrote:
> > >
> > > > The date of the current commitfest is over, here is the current
> status of
> > > > the "September 2022 commitfest."
> > > > There were 296 patches in the commitfest and 58 were get committed.
> > >
> > > Are you moving the open patches to the next commitfest, closing some as
> > > RwF, etc? I'm not clear what the status is, for the November
> commitfest.
> >
> >
> > I am also not clear about that should I move that or wait till November.
> > Anybody guide me
>
> The CF should be marked as closed, and its entries fully processed within
> a few
> days after its final day.
>
> The general rule is that patches that have been waiting on authors for 2
> weeks
> or more without any answer from the author(s) should get returned with
> feedback with some message to the author, and the rest is moved to the next
> commitfest. If you have the time to look at some patches and see if they
> need
> something else, that's always better.
>
> Thanks for your response; I will do that in two days.
--
Ibrar Ahmed.
Senior Software Engineer, PostgreSQL Consultant.
From | Date | Subject | |
---|---|---|---|
Next Message | Alvaro Herrera | 2022-10-06 16:22:42 | Re: Testing DDL Deparser |
Previous Message | Bruce Momjian | 2022-10-06 15:42:28 | Re: An attempt to avoid locally-committed-but-not-replicated-to-standby-transactions in synchronous replication |