Обсуждение: We're getting close to the end of 2020-01 CF
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
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
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
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
Вложения
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
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