Re: 2018-03 Commitfest starts tomorrow - Mailing list pgsql-hackers

From Magnus Hagander
Subject Re: 2018-03 Commitfest starts tomorrow
Date
Msg-id CABUevEzdHG99GMSsc4nOMy-ZBW4trufVy6y1HuCNuuNcJXLsVQ@mail.gmail.com
Whole thread Raw
In response to Re: 2018-03 Commitfest starts tomorrow  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: 2018-03 Commitfest starts tomorrow  (Andres Freund <andres@anarazel.de>)
Re: 2018-03 Commitfest starts tomorrow  (David Steele <david@pgmasters.net>)
Re: 2018-03 Commitfest starts tomorrow  (David Steele <david@pgmasters.net>)
List pgsql-hackers
On Thu, Mar 1, 2018 at 6:42 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
David Steele <david@pgmasters.net> writes:
> I'll be starting the Commitfest at midnight AoE (07:00 ET, 13:00 CET) so
> please get your patches in before then.
> Please remember that if you drop a new and large (or invasive patch)
> into this CF it may be moved to the next CF.
> This last CF for PG11 should generally be restricted to patches that
> have gone through review in prior CFs or are modest in scope.

As of right now, there are 229 entries in this commitfest (not counting
the items already committed or RWF).

It's hard for me to tell for sure, because the activity log page doesn't
stretch back far enough, but I think about 40 of those have been created
in the last 24 hours.  It's certainly well over 20, because the log does
go back far enough to show 21 patch records created since about noon
Wednesday UTC. 

This is NOT how it is supposed to work.  This is gaming the system.

I think that we should summarily bounce to the September 'fest anything
submitted in the last two days; certainly anything that's nontrivial.

So FYI,  it's now 250. Of those, 52 entered into this commitfest on or after 2018-02-27. 4 of those have already been committed, 2 have been bumped to the next CF already,and 1 have been returned with feedback. The remaining ones are:

The remaining 45 are, ordered by time created:

            created            |                                   name
-------------------------------+---------------------------------------------------------------------------
 2018-03-01 04:55:27.137536+00 | CALL optional in PL/pgSQL
 2018-03-01 04:54:22.744169+00 | fixing more format truncation issues
 2018-03-01 04:52:18.850775+00 | chained transactions
 2018-03-01 04:40:15.717802+00 | symlink installs
 2018-03-01 03:43:11.291135+00 | INOUT parameters in procedures
 2018-03-01 02:35:17.891509+00 | SET TRANSACTION in PL/pgSQL
 2018-03-01 01:09:05.311986+00 | PL/pgSQL nested CALL with transactions
 2018-02-28 22:03:10.596235+00 | kNN for SP-GiST
 2018-02-28 20:48:49.571036+00 | ON CONFLICT DO UPDATE for partitioned tables
 2018-02-28 20:25:40.090748+00 | Unlogged tables re-initialization tests
 2018-02-28 18:43:30.279979+00 | Cast jsonb to numeric, int, float, bool
 2018-02-28 18:23:06.778516+00 | Verify Checksums during Basebackups
 2018-02-28 17:51:42.673335+00 | Exclude temp relations from base backup
 2018-02-28 17:30:24.379294+00 | Predicate locking in gin index
 2018-02-28 17:21:13.384903+00 | JIT compiling expressions & tuple deforming
 2018-02-28 16:50:56.90176+00  | Fix "unsupported type" with custom numeric types in convert_to_scalar
 2018-02-28 16:04:58.177284+00 | Reduce amount of WAL generated by CREATE INDEX for gist, gin and sp-gist
 2018-02-28 15:08:41.387825+00 | Direct converting numeric types to bool
 2018-02-28 13:21:51.011607+00 | Parallel Dump to /dev/null
 2018-02-28 12:13:24.574376+00 | Function to track shmem reinit time
 2018-02-28 09:08:57.072633+00 | Transactions involving multiple postgres foreign servers
 2018-02-28 09:05:54.350725+00 | Changing the autovacuum launcher scheduling; oldest table first algorithm
 2018-02-28 08:35:13.412586+00 | Remove DSM_IMPL_NONE
 2018-02-28 08:17:23.041707+00 | Standby cannot catch up primary after pg_rewind
 2018-02-28 08:00:42.722103+00 | Nepali Snowball dictionary
 2018-02-28 05:17:45.996946+00 | committing inside cursor loop
 2018-02-28 05:09:48.206717+00 | pg_proc.prokind column
 2018-02-28 04:59:20.404494+00 | remove pg_class.relhaspkey
 2018-02-28 04:54:20.724058+00 | handling of heap rewrites in logical decoding
 2018-02-28 01:10:13.21312+00  | line_perp() (?-|) is broken.
 2018-02-28 01:06:53.160372+00 | Comment of formdesc() forgets pg_subscription.
 2018-02-28 01:03:20.27799+00  | Correctly inhibit indexonly when multiple occurrence of an index column
 2018-02-28 00:58:30.290382+00 | Increase initdb's fallback value of max_connection to 20
 2018-02-27 21:51:43.73461+00  | Opclass parameters
 2018-02-27 14:52:56.724349+00 | Reopen logfile on SIGHUP
 2018-02-27 14:38:47.501649+00 | ActivePerl 5.24.3 breaks PG compilation in Windows
 2018-02-27 12:08:11.868829+00 | IndexJoin memory problem using spgist and boxes
 2018-02-27 08:20:40.427917+00 | ConvertRowtypeExpr reference errors from partition-wise join
 2018-02-27 08:19:01.520217+00 | Advanced partition matching for partition-wise join
 2018-02-27 08:16:42.223138+00 | Nested ConvertRowtypeExpr optimization
 2018-02-27 02:50:30.05116+00  | Incorrect flag passed to initial_cost_hashjoin()
 2018-02-27 02:46:24.638636+00 | Minor clean-up in dshash.{c,h}
 2018-02-27 02:43:15.150911+00 | Removing shm_mq.c's volatile qualifiers
 2018-02-27 02:41:29.914889+00 | Align isolation tester output
 2018-02-27 02:39:09.2725+00   | Updating parallel.sgml's treatment of parallel joins


Bugfixes should of course still be done, even if submitted late (as we keep doing bugfixes even if there is no CF open at all..)

Trivial ones can certainly be picked up as well.
 
There is no way that we can possibly handle 200+ CF entries in a month.
A large fraction of these are going to end up pushed to September no
matter what, and I think simple fairness demands that we spend our
time on the ones that are not Johnny-come-latelies.

+1.


--

pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: Documenting PROVE_TESTS in section of TAP tests
Next
From: Andres Freund
Date:
Subject: Re: [doc fix] Correct calculation of vm.nr_hugepages