Thread: We're getting close to the end of 2020-01 CF

We're getting close to the end of 2020-01 CF

From
Tomas Vondra
Date:
Hi,

We're about 10 days from the end of the 2020-01 CF. The current status
of the CF is this:

  - Needs review: 118
  - Waiting on Author: 42
  - Ready for Committer: 10
  - Committed: 36
  - Moved to next CF: 3
  - Returned with Feedback: 1
  - Rejected: 3
  - Withdrawn: 2

About half of the WoA patches are inactive for a long time, i.e. have
been marked like that before 2020-01 (and sometimes long before that)
and there have been no substantive updates. The chance of that changing
(i.e. getting a new patch version and a meaningful review) in the last
couple of days of the CF seem slim, and there's plenty of patches that
are being actively discussed, so I plan to start moving those inactive
patches to 2020-03 over the weekend/early next week.

So maybe check if this applies to one of your patches, and try to move
the patch forward.

To some extent this applies to patches in "needs review" state too,
although it's less clear who to ping for those. Maybe if one of your
patches is waiting for a review, try pinging people who already did a
review in the past.



sincerely, your commitfest dictator

-- 
Tomas Vondra                  http://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services



Re: We're getting close to the end of 2020-01 CF

From
Alvaro Herrera
Date:
On 2020-Jan-21, Tomas Vondra wrote:

> About half of the WoA patches are inactive for a long time, i.e. have
> been marked like that before 2020-01 (and sometimes long before that)
> and there have been no substantive updates. The chance of that changing
> (i.e. getting a new patch version and a meaningful review) in the last
> couple of days of the CF seem slim, and there's plenty of patches that
> are being actively discussed, so I plan to start moving those inactive
> patches to 2020-03 over the weekend/early next week.

In the previous commitfest that I ran, I closed as returned-with-feedback
any patches that were waiting-on-author and had not changed for a very
long time.  My rationale was that preserving those dead entries serves
no useful purpose.  If the author or somebody else wants to move the
patch forward, they can post a new version now, or submit a new CF entry
later.  We don't need zombies.

I did provide a list of such patches, so that any interested onlookers
can act.

-- 
Álvaro Herrera                https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services



Re: We're getting close to the end of 2020-01 CF

From
Tomas Vondra
Date:
On Tue, Jan 21, 2020 at 12:25:14PM -0300, Alvaro Herrera wrote:
>On 2020-Jan-21, Tomas Vondra wrote:
>
>> About half of the WoA patches are inactive for a long time, i.e. have
>> been marked like that before 2020-01 (and sometimes long before that)
>> and there have been no substantive updates. The chance of that changing
>> (i.e. getting a new patch version and a meaningful review) in the last
>> couple of days of the CF seem slim, and there's plenty of patches that
>> are being actively discussed, so I plan to start moving those inactive
>> patches to 2020-03 over the weekend/early next week.
>
>In the previous commitfest that I ran, I closed as returned-with-feedback
>any patches that were waiting-on-author and had not changed for a very
>long time.  My rationale was that preserving those dead entries serves
>no useful purpose.  If the author or somebody else wants to move the
>patch forward, they can post a new version now, or submit a new CF entry
>later.  We don't need zombies.
>

Yeah, you're right returning them with feedback seems more appropriate,
given the long inactivity. Plus, the CF app apparently does not allow
moving WoA patches to the next CF anyway.

>I did provide a list of such patches, so that any interested onlookers
>can act.
>

Makes sense. I think the patches this would apply to are:

- fix for BUG #3720: wrong results at using ltree
   https://commitfest.postgresql.org/26/2054/
   (WoA since 2019/11/25)

- Fix Deadlock Issue in Single User Mode When IO Failure Occurs
   https://commitfest.postgresql.org/26/2003/
   (WoA since 2019/11/25)
   
- Use heap_multi_insert for catalog relations
   https://commitfest.postgresql.org/26/2125/
   (WoA since 2019/11/26)

- Expose queryid in pg_stat_activity in log_line_prefix
   https://commitfest.postgresql.org/26/2069/
   (WoA since 2019/11/29)

- Shared Memory Context
   https://commitfest.postgresql.org/26/2325/
   (WoA since 2019/12/01)
   
- Shared system catalog cache
   https://commitfest.postgresql.org/26/2326/
   (WoA since 2019/12/01)

- Transactions involving multiple postgres foreign servers
   https://commitfest.postgresql.org/26/1574/
   (WoA since 2019/12/01)

- Speed up transaction completion faster after many relations are
   accessed in a transaction
   https://commitfest.postgresql.org/26/1993/
   (WoA since 2019/12/01)

- [WIP] Temporal query processing with range types - Temporal
   Normalization
   https://commitfest.postgresql.org/26/2045/
   (WoA since 2019/12/01)

- Autoprepare: implicitly replace literals with parameters and store
   generalized plan
   https://commitfest.postgresql.org/26/1747/
   (WoA since 2019/12/01)

- Shared-memory based stats collector
   https://commitfest.postgresql.org/26/1708/
   (WoA since 2019/12/01)

- Report all I/O errors in buffile.c
   https://commitfest.postgresql.org/26/2365/
   (WoA since 2019/12/10)

- Preserve versions of initdb-created collations in pg_upgrade
   https://commitfest.postgresql.org/26/2328/
   (WoA since 2019/11/29)

- Global temporary tables
   https://commitfest.postgresql.org/26/2233/
   (WoA since 2019/12/01)

- Add more compile-time asserts
   https://commitfest.postgresql.org/26/2286/
   (WoA since 2019/12/24)

- Invalid permission check in pg_stats for functional indexes
   https://commitfest.postgresql.org/26/2274/
   (WoA since 2019/11/28)
   
- Fix PostgreSQL server build and install problems under MSYS2
   https://commitfest.postgresql.org/26/2366/
   (WoA since 2019/12/31)

- FETCH FIRST clause WITH TIES option
   https://commitfest.postgresql.org/26/1844/
   (WoA since 2019/11/28)
   
- Ltree, lquery, and ltxtquery binary protocol support
   https://commitfest.postgresql.org/26/2242/
   (WoA since 2019/11/29)

- Improve search for missing parent downlinks in amcheck
   https://commitfest.postgresql.org/26/2140/
   (WoA since 2019/11/29)

- Run-time pruning for ModifyTable
   https://commitfest.postgresql.org/26/2173/
   (WoA since 2019/11/27)

- Connection string usage for Core Postgresql client applications
   https://commitfest.postgresql.org/26/2354/
   (WoA since 2019/11/25)

- Psql patch to show access methods info
   https://commitfest.postgresql.org/26/1689/
   (WoA since 2019/11/27)

- Row filtering for logical replication
   https://commitfest.postgresql.org/26/2270/
   (WoA since 2019/11/28)

Those are the patches that have been set as WoA before this CF, and have
not been updated since. It's quite possible the state is stale for some
of those patches, although I've tried to check if there were any
messages on the list.

I'll ping the authors off-list too.

regards

-- 
Tomas Vondra                  http://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services



Re: We're getting close to the end of 2020-01 CF

From
Michael Paquier
Date:
On Tue, Jan 21, 2020 at 05:20:17PM +0100, Tomas Vondra wrote:
> Yeah, you're right returning them with feedback seems more appropriate,
> given the long inactivity. Plus, the CF app apparently does not allow
> moving WoA patches to the next CF anyway.

FWIW, I tend to take a base of two weeks as a sensible period of
time as that's half the CF period when I do the classification job.

> Those are the patches that have been set as WoA before this CF, and have
> not been updated since. It's quite possible the state is stale for some
> of those patches, although I've tried to check if there were any
> messages on the list.

You need to be careful about bug fixes, as these are things that we
don't want to lose track of.  Another thing that I noticed in the past
is that some patches are registered as bug fixes, but they actually
implement a new feature.  So there can be tricky cases.
--
Michael

Attachment

Re: We're getting close to the end of 2020-01 CF

From
Alvaro Herrera
Date:
On 2020-Jan-22, Michael Paquier wrote:

> On Tue, Jan 21, 2020 at 05:20:17PM +0100, Tomas Vondra wrote:

> > Those are the patches that have been set as WoA before this CF, and have
> > not been updated since. It's quite possible the state is stale for some
> > of those patches, although I've tried to check if there were any
> > messages on the list.
> 
> You need to be careful about bug fixes, as these are things that we
> don't want to lose track of.

Oh yeah, I forgot to mention the exception for bug fixes. I agree these
should almost never be RwF (or in any way closed other than Committed,
really, except in, err, exceptional cases).

> Another thing that I noticed in the past
> is that some patches are registered as bug fixes, but they actually
> implement a new feature.  So there can be tricky cases.

Oh yeah, I think the CFM should exercise judgement and reclassify.

-- 
Álvaro Herrera                https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services



Re: We're getting close to the end of 2020-01 CF

From
Tomas Vondra
Date:
On Wed, Jan 22, 2020 at 02:09:39PM +0900, Michael Paquier wrote:
>On Tue, Jan 21, 2020 at 05:20:17PM +0100, Tomas Vondra wrote:
>> Yeah, you're right returning them with feedback seems more appropriate,
>> given the long inactivity. Plus, the CF app apparently does not allow
>> moving WoA patches to the next CF anyway.
>
>FWIW, I tend to take a base of two weeks as a sensible period of
>time as that's half the CF period when I do the classification job.
>

Yeah. I've only nagged about patches that have been set to WoA before
the CF began, so far.

>> Those are the patches that have been set as WoA before this CF, and have
>> not been updated since. It's quite possible the state is stale for some
>> of those patches, although I've tried to check if there were any
>> messages on the list.
>
>You need to be careful about bug fixes, as these are things that we
>don't want to lose track of.  Another thing that I noticed in the past
>is that some patches are registered as bug fixes, but they actually
>implement a new feature.  So there can be tricky cases.
>--

Makes sense.

-- 
Tomas Vondra                  http://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services