Thread: Commit Fest 2019-01 is now closed

Hi all,

As per $subject, CF 2019-01 is now closed for business.  Here is the
final score:
Committed: 58.
Moved to next CF: 113.
Withdrawn: 4.
Rejected: 3.
Returned with Feedback: 52.
Total: 230.

I have done a pass over all the remaining entries, updating them
according to their last status (hopefully!).  There may be some
mistakes, so please feel free to update a patch if you think that its
status is not correct.  This CF is no exception in the fact that many
patches had a status on the CF app which was not consistent with the
actual thread.  So please be careful about that if you are an author
or a reviewer.

Thanks,
--
Michael

From: Michael Paquier [mailto:michael@paquier.xyz]
> As per $subject, CF 2019-01 is now closed for business.  Here is the final
> score:
> Committed: 58.
> Moved to next CF: 113.
> Withdrawn: 4.
> Rejected: 3.
> Returned with Feedback: 52.
> Total: 230.

Wow, thank you so much for your hard work.  The last CF for PG 12 should be tough...


Regards
Takayuki Tsunakawa

On Mon, Feb  4, 2019 at 06:34:50AM +0000, Tsunakawa, Takayuki wrote:
> From: Michael Paquier [mailto:michael@paquier.xyz]
> > As per $subject, CF 2019-01 is now closed for business.  Here is the final
> > score:
> > Committed: 58.
> > Moved to next CF: 113.
> > Withdrawn: 4.
> > Rejected: 3.
> > Returned with Feedback: 52.
> > Total: 230.
> 
> Wow, thank you so much for your hard work.  The last CF for PG 12 should be tough...

Agreed.  I am somewhat concerned about this and am wondering what we can
do now to limit problems.

-- 
  Bruce Momjian  <bruce@momjian.us>        http://momjian.us
  EnterpriseDB                             http://enterprisedb.com

+ As you are, so once was I.  As I am, so you will be. +
+                      Ancient Roman grave inscription +

Bruce Momjian <bruce@momjian.us> writes:
> On Mon, Feb  4, 2019 at 06:34:50AM +0000, Tsunakawa, Takayuki wrote:
>> Wow, thank you so much for your hard work.  The last CF for PG 12 should be tough...

> Agreed.  I am somewhat concerned about this and am wondering what we can
> do now to limit problems.

There's been talk periodically of having an aggressive triage effort
to try to sort through the pending patches and decide which ones have
no hope of making it to commit in the last CF.  Then, if we just push
those off to the next cycle immediately and focus our attention on the
ones that do have a credible chance, we might get more of the latter
ones done.

            regards, tom lane

On Tue, Feb  5, 2019 at 11:55:37AM -0500, Tom Lane wrote:
> Bruce Momjian <bruce@momjian.us> writes:
> > On Mon, Feb  4, 2019 at 06:34:50AM +0000, Tsunakawa, Takayuki wrote:
> >> Wow, thank you so much for your hard work.  The last CF for PG 12 should be tough...
> 
> > Agreed.  I am somewhat concerned about this and am wondering what we can
> > do now to limit problems.
> 
> There's been talk periodically of having an aggressive triage effort
> to try to sort through the pending patches and decide which ones have
> no hope of making it to commit in the last CF.  Then, if we just push
> those off to the next cycle immediately and focus our attention on the
> ones that do have a credible chance, we might get more of the latter
> ones done.

The ones I am really worried about are the ones that keep getting
delayed, e.g., CTE inlining, online checksums, multi-variate statistics.

-- 
  Bruce Momjian  <bruce@momjian.us>        http://momjian.us
  EnterpriseDB                             http://enterprisedb.com

+ As you are, so once was I.  As I am, so you will be. +
+                      Ancient Roman grave inscription +

Bruce Momjian <bruce@momjian.us> writes:
> On Tue, Feb  5, 2019 at 11:55:37AM -0500, Tom Lane wrote:
>> There's been talk periodically of having an aggressive triage effort
>> to try to sort through the pending patches and decide which ones have
>> no hope of making it to commit in the last CF.  Then, if we just push
>> those off to the next cycle immediately and focus our attention on the
>> ones that do have a credible chance, we might get more of the latter
>> ones done.

> The ones I am really worried about are the ones that keep getting
> delayed, e.g., CTE inlining, online checksums, multi-variate statistics.

The only thing keeping me from committing CTE inlining today is doubt
about whether we have consensus on the syntax.  Those other two I don't
know the status of.

            regards, tom lane

On Tue, Feb  5, 2019 at 12:02:23PM -0500, Tom Lane wrote:
> Bruce Momjian <bruce@momjian.us> writes:
> > On Tue, Feb  5, 2019 at 11:55:37AM -0500, Tom Lane wrote:
> >> There's been talk periodically of having an aggressive triage effort
> >> to try to sort through the pending patches and decide which ones have
> >> no hope of making it to commit in the last CF.  Then, if we just push
> >> those off to the next cycle immediately and focus our attention on the
> >> ones that do have a credible chance, we might get more of the latter
> >> ones done.
> 
> > The ones I am really worried about are the ones that keep getting
> > delayed, e.g., CTE inlining, online checksums, multi-variate statistics.
> 
> The only thing keeping me from committing CTE inlining today is doubt
> about whether we have consensus on the syntax.  Those other two I don't
> know the status of.

I am thinking we should see which items we really want for PG 12 _now_
and allocate resources/help to get them done, rather than being
surprised they didn't make it.  I am glad we are in good shape with
CTEs, since that has been a long-requested feature.

-- 
  Bruce Momjian  <bruce@momjian.us>        http://momjian.us
  EnterpriseDB                             http://enterprisedb.com

+ As you are, so once was I.  As I am, so you will be. +
+                      Ancient Roman grave inscription +

Hi,

On 2019-02-05 11:55:37 -0500, Tom Lane wrote:
> Bruce Momjian <bruce@momjian.us> writes:
> > On Mon, Feb  4, 2019 at 06:34:50AM +0000, Tsunakawa, Takayuki wrote:
> >> Wow, thank you so much for your hard work.  The last CF for PG 12 should be tough...
> 
> > Agreed.  I am somewhat concerned about this and am wondering what we can
> > do now to limit problems.
> 
> There's been talk periodically of having an aggressive triage effort
> to try to sort through the pending patches and decide which ones have
> no hope of making it to commit in the last CF.  Then, if we just push
> those off to the next cycle immediately and focus our attention on the
> ones that do have a credible chance, we might get more of the latter
> ones done.

I'm planning to do a pass like I did for v11's last CF before the start
of it. That still requires others to chime in, my opinion alone
shouldn't be the sole deciding factor...

What we'd talked about briefly at the Fosdem dev meeting was that a
field 'target release' or 'target branch' would be very useful to be
able to focus attention more. There's plenty stuff in the current CF
that is getting some attention, and deserves a bit more, but that
clearly isn't aimed for v12. Being able to filter by that would be huge.

Magnus has said he'd try creating something like that.

Greetings,

Andres Freund

Hi,

On 2019-02-05 12:02:23 -0500, Tom Lane wrote:
> Bruce Momjian <bruce@momjian.us> writes:
> > On Tue, Feb  5, 2019 at 11:55:37AM -0500, Tom Lane wrote:
> >> There's been talk periodically of having an aggressive triage effort
> >> to try to sort through the pending patches and decide which ones have
> >> no hope of making it to commit in the last CF.  Then, if we just push
> >> those off to the next cycle immediately and focus our attention on the
> >> ones that do have a credible chance, we might get more of the latter
> >> ones done.
> 
> > The ones I am really worried about are the ones that keep getting
> > delayed, e.g., CTE inlining, online checksums, multi-variate statistics.
> 
> The only thing keeping me from committing CTE inlining today is doubt
> about whether we have consensus on the syntax.  Those other two I don't
> know the status of.

Online checksums has been punted by Magnus, because he didn't have time
to work on it so far. I'd provided him with a prototype of the necessary
infrastructure piece.

Greetings,

Andres Freund

On Tue, Feb 5, 2019 at 9:08 AM Andres Freund <andres@anarazel.de> wrote:
> What we'd talked about briefly at the Fosdem dev meeting was that a
> field 'target release' or 'target branch' would be very useful to be
> able to focus attention more. There's plenty stuff in the current CF
> that is getting some attention, and deserves a bit more, but that
> clearly isn't aimed for v12. Being able to filter by that would be huge.

That sounds like a good idea to me.

-- 
Peter Geoghegan

> On 6 Feb 2019, at 21:09, Magnus Hagander <magnus@hagander.net> wrote:

> This has now been pushed and is available. I've set it up with stable, 12 and 13 as possible versions for now, but I
havenot added any tags to the existing patches (except for one, in order to test it). 

The patch has omitted the ending </td> tag from the patch view, fixed in the
attached diff.

cheers ./daniel

> On 6 Feb 2019, at 21:37, Daniel Gustafsson <daniel@yesql.se> wrote:
>
>> On 6 Feb 2019, at 21:09, Magnus Hagander <magnus@hagander.net> wrote:
>
>> This has now been pushed and is available. I've set it up with stable, 12 and 13 as possible versions for now, but I
havenot added any tags to the existing patches (except for one, in order to test it). 
>
> The patch has omitted the ending </td> tag from the patch view, fixed in the
> attached diff.

The main view also needs to bump the colspan of the category headings, as per
the attached diff.

cheers ./daniel

> On 6 Feb 2019, at 21:47, Magnus Hagander <magnus@hagander.net> wrote:
>
> On Wed, Feb 6, 2019 at 9:46 PM Daniel Gustafsson <daniel@yesql.se <mailto:daniel@yesql.se>> wrote:
> > On 6 Feb 2019, at 21:37, Daniel Gustafsson <daniel@yesql.se <mailto:daniel@yesql.se>> wrote:
> >
> >> On 6 Feb 2019, at 21:09, Magnus Hagander <magnus@hagander.net <mailto:magnus@hagander.net>> wrote:
> >
> >> This has now been pushed and is available. I've set it up with stable, 12 and 13 as possible versions for now, but
Ihave not added any tags to the existing patches (except for one, in order to test it). 
> >
> > The patch has omitted the ending </td> tag from the patch view, fixed in the
> > attached diff.
>
> The main view also needs to bump the colspan of the category headings, as per
> the attached diff.
>
>
> Double argh. I had that one fixed, but managed to unfix it in a merge conflict resoluation.

Thanks for applying, the rendered HTML looks fine now.

cheers ./daniel

On 2019-Feb-06, Magnus Hagander wrote:

> This has now been pushed and is available. I've set it up with stable, 12
> and 13 as possible versions for now, but I have not added any tags to the
> existing patches (except for one, in order to test it).

I added a few more tags.  Cool stuff, thanks!

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

On 06/02/2019 21:09, Magnus Hagander wrote:
> This has now been pushed and is available. I've set it up with stable,
> 12 and 13 as possible versions for now, but I have not added any tags to
> the existing patches (except for one, in order to test it).

What is the meaning of this?  If something is meant for 13, shouldn't it
be moved to the next commit fest?

I find the current display a bit hard to read.  If we are going to use
the white-on-color style, perhaps each version could have a different
color.  Or just make it plain black-on-white text.

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

Hi,

On 2019-02-07 12:53:39 +0100, Peter Eisentraut wrote:
> On 06/02/2019 21:09, Magnus Hagander wrote:
> > This has now been pushed and is available. I've set it up with stable,
> > 12 and 13 as possible versions for now, but I have not added any tags to
> > the existing patches (except for one, in order to test it).
> 
> What is the meaning of this?  If something is meant for 13, shouldn't it
> be moved to the next commit fest?

Why? There's plenty stuff that's chugging along in development but ought
to be processed at less urgency / by different people, than the stuff
targeted to be committed soon. It's already frustrating to contribute to
postgresql for new people, but if they don't get feedback for half a
year because they submitted around December / January it's almost
guaranteed that they vanish.  Additionally, there's an increasing amount
of development projects that are too large to complete in a single
cycle, and if we just stop looking at them for half a year, they'll also
not succeed.

Greetings,

Andres Freund

On 08/02/2019 00:53, Peter Eisentraut wrote:
> On 06/02/2019 21:09, Magnus Hagander wrote:
>> This has now been pushed and is available. I've set it up with stable,
>> 12 and 13 as possible versions for now, but I have not added any tags to
>> the existing patches (except for one, in order to test it).
> What is the meaning of this?  If something is meant for 13, shouldn't it
> be moved to the next commit fest?
>
> I find the current display a bit hard to read.  If we are going to use
> the white-on-color style, perhaps each version could have a different
> color.  Or just make it plain black-on-white text.
>
If your eyesight is poor, then odd colour combinations like white on 
grey, or other colours, is hard to read.

Ten years ago, before about 7 eye operations, poor contrast would be 
extremely difficult, if not impossible, for me to read.

Remember also that about 1 in 12 men are colour blind.


Cheers,
Gavin

On Thu, Feb 7, 2019 at 4:02 AM Andres Freund <andres@anarazel.de> wrote:
> On 2019-02-07 12:53:39 +0100, Peter Eisentraut wrote:
> > What is the meaning of this?  If something is meant for 13, shouldn't it
> > be moved to the next commit fest?
>
> Why? There's plenty stuff that's chugging along in development but ought
> to be processed at less urgency / by different people, than the stuff
> targeted to be committed soon. It's already frustrating to contribute to
> postgresql for new people, but if they don't get feedback for half a
> year because they submitted around December / January it's almost
> guaranteed that they vanish.

+1. Let's not disincentivize acknowledging that v13 is the target release.

I also don't think it's a good idea to force patch authors to take a
position. Novice authors are particularly likely to make the wrong
call.


--
Peter Geoghegan

Andres Freund <andres@anarazel.de> writes:

> There's plenty stuff that's chugging along in development but ought to
> be processed at less urgency / by different people, than the stuff
> targeted to be committed soon. It's already frustrating to contribute
> to postgresql for new people, but if they don't get feedback for half
> a year because they submitted around December / January it's almost
> guaranteed that they vanish.  Additionally, there's an increasing
> amount of development projects that are too large to complete in a
> single cycle, and if we just stop looking at them for half a year,
> they'll also not succeed.

I definitely did this - and I don't think success can be declared in my
case yet.  Would like to talk about that for a moment if that's alright.

GSSAPI encryption was first submitted 2015-07-02.  Discussion on it
continued until 2016-08-01, when I vanished.  Discussion included 118
messages, 49 of which I sent myself, and 13 separate revisions.  At that
point I had gone way over the allotted time to spend on this, and had to
move on to other things.  The account tracking on the commitfest app
wasn't as good then, but this corresponds to 4 commitfests.

Second push started 2018-05-23 and is ongoing.  Discussion has been much
quieter - 30 messages, 10 mine - and 7 revisions (mostly due to cfbot).
Since the commitfest webpage supports github login now, the count for
second push is accurate: 5 commitfests.

So I'm at 9 commitfests total (over 2 years).  The total amount of time
spent on this is incredibly daunting.  And this isn't an isolated case;
for instance, at the top of the current commitfest is
https://commitfest.postgresql.org/22/528/ which has been in 14
commitfests.  14 - this'll be 3 years next month.  Others have 11, 10,
10, 8...  (I didn't dig into the tracking on this, so they might be
higher for the same reason my count is higher than is reflected.)

postgresql is an amazing piece of software, and it's really cool to have
something to contribute to it.  And I think that the reviews I've
received have been from people who care genuinely that it keeps being
amazing.  But if I weren't regularly dealing with open source and quirky
upstreams for my day job, I would be long gone.  Even so, no contributor
has unlimited time; even for us corporate contributors, management will
eventually decide to solve the problem a different way.

Thanks for letting me get that off my chest.  Happy hacking!

Thanks,
--Robbie

From: Gavin Flower [mailto:GavinFlower@archidevsys.co.nz]
> Remember also that about 1 in 12 men are colour blind.

Thank you for referring to it.  I'm one of them -- I'm visually impaired and use screen reader software.  I didn't
noticeany change in the 2019-03 CF page.  I thought "Ver" is the new column.
 


Regards
Takayuki Tsunaakwa

From: Bruce Momjian [mailto:bruce@momjian.us]
> I am thinking we should see which items we really want for PG 12 _now_
> and allocate resources/help to get them done, rather than being
> surprised they didn't make it.  I am glad we are in good shape with
> CTEs, since that has been a long-requested feature.

I want the partitioning performance to be comparable to a certain commercial DBMS, and Horiguchi-san's "protect
syscache..." to limit the upper size of syscache/relcache.  Otherwise, our organization may be put in a difficult
situation... Anyway, I recognize my colleagues and I also have to review others' patches.
 

I'm sorry if I repeat what someone proposed in the past, but it would be nice if the CF app could show the number of
modifiedlines (added + deleted) for each patch, e.g., the last line of diffstat command output.  That would help young
newbiesto choose patches.
 

Regards
Takayuki Tsunakawa

On 08/02/2019 12:27, Magnus Hagander wrote:
> I'd be more than happy for somebody with morge knowledge of such matters
> than me to think up a better color scheme. The only reason it has those
> colors is that they're the default ones in the Bootstrap CSS framework.

Can we have that column just normal black-and-white?

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

From: Chris Travers [mailto:chris.travers@adjust.com]
> On Fri, Feb 8, 2019 at 9:40 AM Tsunakawa, Takayuki
> <tsunakawa.takay@jp.fujitsu.com> wrote:
>     I'm sorry if I repeat what someone proposed in the past, but it
> would be nice if the CF app could show the number of modified lines (added
> + deleted) for each patch, e.g., the last line of diffstat command output.
> That would help young newbies to choose patches.
> 
> 
> 
> An important prerequisite here would be to list all patches on the most
> recent email.  Right now it just lists one so you have to follow the link
> to the hackers list entry and look at each patch one at a time.
> 
> So if we could grab all attachments ending in .diff or .patch and list line
> counts, that would be a welcome improvement.

I understood it may be difficult to extract all patch files in a single email.  Sorry, I can't tell whether it's
possible...

Another idea is to add the number of lines of the mail thread.  Reviewers can expect that a patch with short discussion
maybe easy to work on, although it's not always true of course.  Long mail threads are hard to understand for those who
arenew and/or not good at English.
 


Regards
Takayuki Tsunakawa

On 2/5/19 7:08 PM, Andres Freund wrote:
> Hi,
> 
> On 2019-02-05 11:55:37 -0500, Tom Lane wrote:
>> Bruce Momjian <bruce@momjian.us> writes:
>>> On Mon, Feb  4, 2019 at 06:34:50AM +0000, Tsunakawa, Takayuki wrote:
>>>> Wow, thank you so much for your hard work.  The last CF for PG 12 should be tough...
>>
>>> Agreed.  I am somewhat concerned about this and am wondering what we can
>>> do now to limit problems.
>>
>> There's been talk periodically of having an aggressive triage effort
>> to try to sort through the pending patches and decide which ones have
>> no hope of making it to commit in the last CF.  Then, if we just push
>> those off to the next cycle immediately and focus our attention on the
>> ones that do have a credible chance, we might get more of the latter
>> ones done.
> 
> I'm planning to do a pass like I did for v11's last CF before the start
> of it. That still requires others to chime in, my opinion alone
> shouldn't be the sole deciding factor...

+1. I'll certainly be commenting.

I'm planning to do CFM duties again this year if there are no objections...

-- 
-David
david@pgmasters.net

David Steele <david@pgmasters.net> writes:
> I'm planning to do CFM duties again this year if there are no objections...

Excellent!  Particularly for the last CF of a cycle, we badly need an
active CFM, so it's great that you're willing to take it on.

            regards, tom lane

On 2019-02-10 20:30, Magnus Hagander wrote:
> On Fri, Feb 8, 2019 at 2:12 PM Peter Eisentraut
> <peter.eisentraut@2ndquadrant.com
> <mailto:peter.eisentraut@2ndquadrant.com>> wrote:
> 
>     On 08/02/2019 12:27, Magnus Hagander wrote:
>     > I'd be more than happy for somebody with morge knowledge of such
>     matters
>     > than me to think up a better color scheme. The only reason it has
>     those
>     > colors is that they're the default ones in the Bootstrap CSS
>     framework.
> 
>     Can we have that column just normal black-and-white?
> 
> 
> Sure! Do you mean like the update pushed now, or to remove the label
> completely?

What you pushed is white-on-black, not black-on-white that I meant.
Sorry, my "black-and-white" was obviously ambiguous.

If we're going to have a the white-on-something scheme, then it would be
useful to have different colors for different releases.  Otherwise there
is no value in it and it should just be plain black-on-white text.

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