Thread: [HACKERS] Commit fest 2017-01 will begin soon!

Hi all,

As mentioned a couple of weeks back, I am fine to work as commit fest
manager for 2017-01.

Here is the commit fest status at the moment I am writing this email:
Needs review: 68.
Waiting on Author: 17.
Ready for Committer: 18.
Committed: 27.
Rejected: 2.
Returned with Feedback: 6.
Total: 138.
So there are many of them, though there are not that many new entries
as many patches have been moved from the last CF to this one.

There are still a couple of days to register patches! So if you don't
want your fancy feature to be forgotten, please add it in time to the
CF app. Speaking of which, I am going to have a low bandwidth soon as
that's a period of National Holidays in Japan for the new year, and I
don't think I'll be able to mark the CF as in progress AoE time. So if
somebody could do it for me that would be great :)

Thanks,
-- 
Michael

On Tue, Dec 27, 2016 at 12:41 PM, Michael Paquier
<michael.paquier@gmail.com> wrote:
> There are still a couple of days to register patches! So if you don't
> want your fancy feature to be forgotten, please add it in time to the
> CF app. Speaking of which, I am going to have a low bandwidth soon as
> that's a period of National Holidays in Japan for the new year, and I
> don't think I'll be able to mark the CF as in progress AoE time. So if
> somebody could do it for me that would be great :)

Reminder: just 1 more day. Be careful to have your patches registered!
-- 
Michael

On Mon, Jan 2, 2017 at 2:15 AM, Fabrízio de Royes Mello
<fabriziomello@gmail.com> wrote:
> I changed the status to "In Progress".

Thanks for covering my absence.
--
Michael

On Tue, Jan 3, 2017 at 8:41 PM, Michael Paquier
<michael.paquier@gmail.com> wrote:
> On Mon, Jan 2, 2017 at 2:15 AM, Fabrízio de Royes Mello
> <fabriziomello@gmail.com> wrote:
>> I changed the status to "In Progress".
>
> Thanks for covering my absence.

To all hackers,

Commit fest 2017-01 has now officially begun. With this commit fest
included, there are still two sessions to get a new feature included
in Postgres 10.

If you are the author of one or more patches, please don't forget to
review other patches with an equivalent difficulty to balance with the
patches you have submitted.

If you review patches, please coordinate with the author. The worse
that can happen to a patch is that someone is registered as reviewer,
meaning that there is a guarantee that he/she will look at the patch
within the timeframe of the commit fest, but he/she does not show up
at the end. Looking at patches that touch areas of the code that you
are not an expert of is always well appreciated. The challenge is
surely tougher, but you gain confidence and knowledge for your future
work on Postgres core. As for the last commit fest, it is forecasted
that there will be more patches than reviewers, so even if you have
not submitted any patch, of course feel free to look at what is
present.

And of course, don't forget that any input is useful input. Just
looking at a patch and let the user know the following things is
always appreciated. So asking those questions first usually makes the
most sense:
- Does the patch apply cleanly? For example look at if `git diff
--check` complains or not.
- Does the patch include documentation? Does the patch need
documentation or a README?
- Does the patch need, include and pass regression tests?
- Does the patch respect the code format of the project? This portion
of the documentation is useful:
https://www.postgresql.org/docs/devel/static/source.html

Here are now the current stats of the patches:
- Needs review: 82.
- Waiting on Author: 18.
- Ready for Committer: 18.
Meaning that some effort is required from committers and reviewers to
get into a better balance. For the authors of the patches waiting for
their input, please avoid letting your patch in a latent state for too
long.

And of course, please double-check that the status of your patch on
the CF app (https://commitfest.postgresql.org/12/) is set according to
the status of the thread.

Let's have a productive CF for Postgres 10! And the show begins..
Thanks.
--
Michael

On Wed, Jan 4, 2017 at 4:02 PM, Michael Paquier
<michael.paquier@gmail.com> wrote:
> Here are now the current stats of the patches:
> - Needs review: 82.
> - Waiting on Author: 18.
> - Ready for Committer: 18.
> Meaning that some effort is required from committers and reviewers to
> get into a better balance. For the authors of the patches waiting for
> their input, please avoid letting your patch in a latent state for too
> long.
>
> And of course, please double-check that the status of your patch on
> the CF app (https://commitfest.postgresql.org/12/) is set according to
> the status of the thread.
>
> Let's have a productive CF for Postgres 10! And the show begins..
> Thanks.

There is one week left for this commit fest, and now is the time to
push for things that have a chance to get in. As of now, there is a
total of 25 patches waiting for some love from a committer.

In the category of Bug Fixes, there are the following things that
deserve attention:
- pgwin32_is_service not checking if SECURITY_SERVICE_SID is disabled,
Windows-only patch, and a bug fix.
- Cascading standby cannot catch up and get stuck emitting the same
message repeatedly, a 9.3-only bug fix.
- Potential data loss of 2PC files, a bug fix to address the fact that
pg_twophase is never fsync()'d.
All those patches apply on multiple branches.

In the category of Clients, there are some as well:
- pgbench - more operators and functions.
- pgpassfile connection option.
- pg_dump, pg_dumpall and data durability.

Now for Miscellaneous:
- slab-like memory allocators for reorderbuffer
- Rename pg_switch_xlog to pg_switch_wal, the name is misleading here
as this is basically renaming all the system functions including the
term "xlog" prefix to "wal".
- Add GUCs for predicate lock promotion thresholds
- An isolation test for SERIALIZABLE READ ONLY DEFERRABLE

For Monitoring & Control:
- amcheck (B-Tree integrity checking tool). This patch is in such a
state for a rather long time...

For Performance:
- Group mode for CLOG updates.
- Vacuum: allow usage of more than 1GB of work mem.
- Parallel Index Scans.
- Unique Joins

For Replication & Recovery:
- Write Ahead Logging for Hash Indexes.
- WAL consistency check facility
- Reset slot xmin when HS feedback is turned off while standby is shut down

For server features:
- Forbid use of LF and CR characters in database and role names.
- XMLTABLE function
- background sessions
- pg_background contrib module proposal
- A contrib extension to help prevent common errors in DML
- Add pg_current_logfile() function to obtain the current log file
used by the syslogger.
- pg_xlogdump follow into the future when specifying filename. Magnus,
are you going to take care of that?

As of the current score of the CF, for a total of 155 patches, 52 have
been committed, 3 rejected and 7 marked as returned with feedback. It
may look low, but actually it is not that bad by experience looking at
those numbers.

There is also a very high number of patches waiting for input from the
author, so please be sure to update your patch status correctly, or
send a new version to address the comments from reviewers.
-- 
Michael

From: pgsql-hackers-owner@postgresql.org
> [mailto:pgsql-hackers-owner@postgresql.org] On Behalf Of Michael Paquier
> - Cascading standby cannot catch up and get stuck emitting the same message
> repeatedly, a 9.3-only bug fix.

Thank you for your hard work as a CFM.  For a trivial note, this is for 9.2 only, not 9.3.

Regards
Takayuki Tsunakawa

Michael, all,

* Michael Paquier (michael.paquier@gmail.com) wrote:
> There is one week left for this commit fest, and now is the time to
> push for things that have a chance to get in. As of now, there is a
> total of 25 patches waiting for some love from a committer.

Many thanks for your work as CFM this month!

> In the category of Clients, there are some as well:
> - pgbench - more operators and functions.

I don't mind working to review these, but my recollection is that
there's actually still question about just what operators, what
functions, and how we want to handle them.  In other words, this
particular patch, imv, could really use a 'summary' email, most likely
from the author, regarding the various opinions raised and the different
view-points presented.  Otherwise, I'm not sure it's really going to
make much more progress.

> - pgpassfile connection option.
> - pg_dump, pg_dumpall and data durability.

I'm interested in these.  I had thought the data durability one had
another committer already interested and involved, but if not, I may get
to it.

> Now for Miscellaneous:
> - Rename pg_switch_xlog to pg_switch_wal, the name is misleading here
> as this is basically renaming all the system functions including the
> term "xlog" prefix to "wal".

I'm a definite +1 on that happening but, for as much as it's marked
'ready for committer', it's entirely without consensus.  I'm not sure
how to resolve that- we could ask some committee to investigate it
further and provide a final determination (core?  some other set of
folks?), or simply tally the votes cast and decide to go with whatever
the result of that is, or change the options (and then figure out how to
decide between whatever the new options are..).

> For Monitoring & Control:
> - amcheck (B-Tree integrity checking tool). This patch is in such a
> state for a rather long time...

I'm a big +1 on having this included.  In my view, this is similar to
the 'enable checksums by default' question, but without nearly *all* of
the downside.  There's no performance impact, there's no usability
issue, the only concerns that I see off-hand are serious bugs that
screw things up and the possibility that it throws an error when nothing
is wrong., neither of which look very likely considering it's been used
extensivly by a number of people and quite a bit at Heroku, as I
understand it.  At this point, I tend to doubt that we're going to see
such errors without the broader community embracing and using it, which
means. to me at least, that it's ready to go into core/contrib.

> For server features:
> - Forbid use of LF and CR characters in database and role names.

I'll try and take a look at this.  In other words, for me, this comes
before the pgpassfile/pg_dump data durability stuff.  I have a couple
other things to clear off my plate, but I expect to get those taken care
of and still have time to handle this too.

> As of the current score of the CF, for a total of 155 patches, 52 have
> been committed, 3 rejected and 7 marked as returned with feedback. It
> may look low, but actually it is not that bad by experience looking at
> those numbers.

We've certainly had some really big patches land during this CF.  I'm
hopeful that we won't have any "really big" patches landing for the last
CF, or PG10 is going to be difficult to wrestle out the door.

Thanks again, Michael!

Stephen

On Mon, Jan 23, 2017 at 1:17 PM, Michael Paquier
<michael.paquier@gmail.com> wrote:
> As of the current score of the CF, for a total of 155 patches, 52 have
> been committed, 3 rejected and 7 marked as returned with feedback. It
> may look low, but actually it is not that bad by experience looking at
> those numbers.

The CF finishing soon, I have done a first pass on the patches
remaining on it, moving patches to the next CF or updating them. There
are still 48 patches still on the tracker when writing this email:
Needs review: 32.
Ready for Committer: 16.
This requires a certain amount of energy to classify, so if you would
like spare a bit of HP/MP to the CFM, feel free to cleanup your
patches or the ones you are reviewing.

@all: If I have updated your patch in a state that you think is not
appropriate, feel free to complain on the thread of the patch or here.
That's fine.
Thanks,
-- 
Michael

On Tue, Jan 31, 2017 at 4:01 PM, Michael Paquier
<michael.paquier@gmail.com> wrote:
> The CF finishing soon, I have done a first pass on the patches
> remaining on it, moving patches to the next CF or updating them. There
> are still 48 patches still on the tracker when writing this email:
> Needs review: 32.
> Ready for Committer: 16.
> This requires a certain amount of energy to classify, so if you would
> like spare a bit of HP/MP to the CFM, feel free to cleanup your
> patches or the ones you are reviewing.
>
> @all: If I have updated your patch in a state that you think is not
> appropriate, feel free to complain on the thread of the patch or here.
> That's fine.

After 3 days and 90 patches spamming everybody on this -hackers, the
CF is now *closed*. Here is the final score of this session:
Committed: 58.
Moved to next CF: 70.
Rejected: 4.
Returned with Feedback: 23.
Total: 155.

It is nice to see that many people have registered as reviewers and
that much has been done. I have finished with the impression that
there has been more commitment in this area compared to the past.
Thanks to all the people involved!
-- 
Michael

On Thu, Feb 2, 2017 at 8:50 AM, Michael Paquier
<michael.paquier@gmail.com> wrote:
> On Tue, Jan 31, 2017 at 4:01 PM, Michael Paquier
> <michael.paquier@gmail.com> wrote:
>> The CF finishing soon, I have done a first pass on the patches
>> remaining on it, moving patches to the next CF or updating them. There
>> are still 48 patches still on the tracker when writing this email:
>> Needs review: 32.
>> Ready for Committer: 16.
>> This requires a certain amount of energy to classify, so if you would
>> like spare a bit of HP/MP to the CFM, feel free to cleanup your
>> patches or the ones you are reviewing.
>>
>> @all: If I have updated your patch in a state that you think is not
>> appropriate, feel free to complain on the thread of the patch or here.
>> That's fine.
>
> After 3 days and 90 patches spamming everybody on this -hackers, the
> CF is now *closed*. Here is the final score of this session:
> Committed: 58.
> Moved to next CF: 70.
> Rejected: 4.
> Returned with Feedback: 23.
> Total: 155.
>
> It is nice to see that many people have registered as reviewers and
> that much has been done. I have finished with the impression that
> there has been more commitment in this area compared to the past.
> Thanks to all the people involved!
>

Many thanks to you for running the show.  I think it might be okay if
one consolidated mail is sent for all the patches that are marked
"Returned with Feedback" or "Rejected" or "Moved to next CF".  OTOH,
there is some value in sending a separate mail for each patch so that
people can argue on the decision by CFM for one particular patch, but
not sure if it worth.


-- 
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com

On Thu, Feb 2, 2017 at 1:23 PM, Amit Kapila <amit.kapila16@gmail.com> wrote:
> Many thanks to you for running the show.  I think it might be okay if
> one consolidated mail is sent for all the patches that are marked
> "Returned with Feedback" or "Rejected" or "Moved to next CF".  OTOH,
> there is some value in sending a separate mail for each patch so that
> people can argue on the decision by CFM for one particular patch, but
> not sure if it worth.

People tend to look at emails they are directly on in CC, that's why I
prefer sending individual emails.
-- 
Michael

On 2/1/17 10:39 PM, Michael Paquier wrote:
> On Thu, Feb 2, 2017 at 1:23 PM, Amit Kapila <amit.kapila16@gmail.com> wrote:
>> Many thanks to you for running the show.  I think it might be okay if
>> one consolidated mail is sent for all the patches that are marked
>> "Returned with Feedback" or "Rejected" or "Moved to next CF".  OTOH,
>> there is some value in sending a separate mail for each patch so that
>> people can argue on the decision by CFM for one particular patch, but
>> not sure if it worth.
>
> People tend to look at emails they are directly on in CC, that's why I
> prefer sending individual emails.

BTW, the app also sends email notifications to anyone named on a patch 
(or at least I got notifications). Having a human spend time doing that 
by hand seems pretty silly.

Since the app also knows about the email threads, presumably it could 
send notifications to relevant threads as well.
-- 
Jim Nasby, Data Architect, Blue Treble Consulting, Austin TX
Experts in Analytics, Data Architecture and PostgreSQL
Data in Trouble? Get it in Treble! http://BlueTreble.com
855-TREBLE2 (855-873-2532)