Re: 2018-03 CFM

[Andrey Borodin]

> 7 марта 2018 г., в 12:00, Michael Paquier  написал(а):
> 
> On Wed, Mar 07, 2018 at 11:56:01AM +0500, Andrey Borodin wrote:
>> Actually, as for now, it is impossible to register patch at CF
>> 2018-09. At least I do not see the "new patch" button. May be CF
>> should be open if 2018-03 is in progress? 
> 
> OK, I was able to see the button but that may be due to my rights on the
> CF app.  I have switched the status to "Open".  Can you register your
> new patch now?
Yes, it works. Thanks! 
> (I would recommend helping with patch reviews instead of
> posting new things which are not bug fixes by the way as long as the CF
> is running.)
Sure, I'm reviewing some patches :)
There are patch movement from 03 to 09 in progress. And I decided to move my 
old things too. There's nothing new. :)

Best regards, Andrey Borodin.

Re: 2018-03 CFM

[Michael Paquier]

On Wed, Mar 07, 2018 at 11:56:01AM +0500, Andrey Borodin wrote:
> Actually, as for now, it is impossible to register patch at CF
> 2018-09. At least I do not see the "new patch" button. May be CF
> should be open if 2018-03 is in progress? 

OK, I was able to see the button but that may be due to my rights on the
CF app.  I have switched the status to "Open".  Can you register your
new patch now?  (I would recommend helping with patch reviews instead of
posting new things which are not bug fixes by the way as long as the CF
is running.)
--
Michael


signature.asc
Description: PGP signature

Re: 2018-03 CFM

[Andrey Borodin]

Hi, Michael!

> 27 февр. 2018 г., в 6:34, Michael Paquier  написал(а):
> 
> On Mon, Feb 26, 2018 at 02:03:56PM -0500, Tom Lane wrote:
>> David Steele  writes:
>>> I'm planning to fill the CFM role, unless there are objections.
>> 
>> Thanks for volunteering!
> 
> +1.  I have also added a new commit fest entry marked as future, which
> will likely be used for 12 development:
> https://commitfest.postgresql.org/18/
> 2018-09 is a tentative name, please don't take that as a decided date as
> this will be discussed in Ottawa during the dev meeting.
> 
> This matters for hackers as once a CF is marked as in-progress, there is
> no way to register a patch in it.  And in the case of this March's CF,
> there would be no places where such future patches could go.


Actually, as for now, it is impossible to register patch at CF 2018-09. At 
least I do not see the "new patch" button. May be CF should be open if 2018-03 
is in progress?

Best regards, Andrey Borodin.

Re: 2018-03 CFM

[Andres Freund]

On 2018-03-05 20:49:02 -0500, David Steele wrote:
> On 3/5/18 8:33 PM, Thomas Munro wrote:
> > On Tue, Mar 6, 2018 at 1:00 PM, David Steele  wrote:
> >> I've been using commitfest.cputube.org for reference since the last CF,
> >> though I'm unsure if it rechecks patches when master changes, so I do
> >> that manually.  Anyway, that's probably too much to ask since every push
> >> to master would set off a 100+ builds on Travis.
> >>
> >> Maybe just reapply once a day when master changes?  And only rebuild if
> >> the patch changes?  Not perfect, but it would work in most cases.
> >>
> >> I use Travis for the pgBackRest project, and I try to be considerate of
> >> the free resources.  I dislike the idea of throwing a ton of builds at
> >> them without considering what would be most useful.
> > 
> > It's triggered by new patches AND new commits.  Since I want to be
> > polite, I try to avoid having more than 2 builds going at a time.
> > They generously invite open source projects like us to run up to 5
> > builds concurrently for free, so I thought I was being at least a
> > little bit considerate, though I guess I could drop it down to 1.  It
> > goes in rotating order of Commitfest ID and waits in between to limit
> > the rate. The constant stream of both commits and patches during a
> > 200+ entry Commitfest mean that it's effectively building around the
> > clock and each CF entry gets retested about twice a day.  Perhaps I
> > could make it smarter... I'll think about that.  Thanks!
> 
> Another option would be too look at their graphs and figure out when
> their peak times are, then ramp up the builds outside that time.
> 
> Even so, 2 builds at a time sounds pretty moderate to me.

Have we pinged them about what they're ok with? In previous interactions
I had with them they were pretty responsive.

Greetings,

Andres Freund

Re: 2018-03 CFM

[David Steele]

On 3/5/18 8:33 PM, Thomas Munro wrote:
> On Tue, Mar 6, 2018 at 1:00 PM, David Steele  wrote:
>> I've been using commitfest.cputube.org for reference since the last CF,
>> though I'm unsure if it rechecks patches when master changes, so I do
>> that manually.  Anyway, that's probably too much to ask since every push
>> to master would set off a 100+ builds on Travis.
>>
>> Maybe just reapply once a day when master changes?  And only rebuild if
>> the patch changes?  Not perfect, but it would work in most cases.
>>
>> I use Travis for the pgBackRest project, and I try to be considerate of
>> the free resources.  I dislike the idea of throwing a ton of builds at
>> them without considering what would be most useful.
> 
> It's triggered by new patches AND new commits.  Since I want to be
> polite, I try to avoid having more than 2 builds going at a time.
> They generously invite open source projects like us to run up to 5
> builds concurrently for free, so I thought I was being at least a
> little bit considerate, though I guess I could drop it down to 1.  It
> goes in rotating order of Commitfest ID and waits in between to limit
> the rate. The constant stream of both commits and patches during a
> 200+ entry Commitfest mean that it's effectively building around the
> clock and each CF entry gets retested about twice a day.  Perhaps I
> could make it smarter... I'll think about that.  Thanks!

Another option would be too look at their graphs and figure out when
their peak times are, then ramp up the builds outside that time.

Even so, 2 builds at a time sounds pretty moderate to me.

-- 
-David
da...@pgmasters.net

Re: 2018-03 CFM

[Thomas Munro]

On Tue, Mar 6, 2018 at 1:00 PM, David Steele  wrote:
> I've been using commitfest.cputube.org for reference since the last CF,
> though I'm unsure if it rechecks patches when master changes, so I do
> that manually.  Anyway, that's probably too much to ask since every push
> to master would set off a 100+ builds on Travis.
>
> Maybe just reapply once a day when master changes?  And only rebuild if
> the patch changes?  Not perfect, but it would work in most cases.
>
> I use Travis for the pgBackRest project, and I try to be considerate of
> the free resources.  I dislike the idea of throwing a ton of builds at
> them without considering what would be most useful.

It's triggered by new patches AND new commits.  Since I want to be
polite, I try to avoid having more than 2 builds going at a time.
They generously invite open source projects like us to run up to 5
builds concurrently for free, so I thought I was being at least a
little bit considerate, though I guess I could drop it down to 1.  It
goes in rotating order of Commitfest ID and waits in between to limit
the rate. The constant stream of both commits and patches during a
200+ entry Commitfest mean that it's effectively building around the
clock and each CF entry gets retested about twice a day.  Perhaps I
could make it smarter... I'll think about that.  Thanks!

-- 
Thomas Munro
http://www.enterprisedb.com

Re: 2018-03 CFM

[David Steele]

On 3/5/18 6:06 PM, Thomas Munro wrote:
> On Sat, Mar 3, 2018 at 1:18 AM, Aleksander Alekseev
>>
>> I don't think commitfest.cputube.org has the SQL data on whether patch
>> pass the tests. It just displays SVG images from travis-ci.org. Also
>> unfortunately both commitfest.postgresql.org and commitfest.cputube.org
>> currently don't have any kind of public API and don't allow to export
>> data, e.g. in CSV or JSON.
> 
> My current plan is to propose that we post automated apply/build
> results into the Commitfest app itself so that it can show them, and
> then shut down commitfest.cputube.org.

+1

> The reason commitfest.cputube.org is so limited, not integrated yet
> and running on a strange domain name is because I decided to build an
> independent proof-of-concept first.  I imagined that negotiating with
> many busy people on how such a thing should work and what would even
> be possible first would be more likely to stall, based on previous
> experiences with humans :-D

I've been using commitfest.cputube.org for reference since the last CF,
though I'm unsure if it rechecks patches when master changes, so I do
that manually.  Anyway, that's probably too much to ask since every push
to master would set off a 100+ builds on Travis.

Maybe just reapply once a day when master changes?  And only rebuild if
the patch changes?  Not perfect, but it would work in most cases.

I use Travis for the pgBackRest project, and I try to be considerate of
the free resources.  I dislike the idea of throwing a ton of builds at
them without considering what would be most useful.

Regards,
-- 
-David
da...@pgmasters.net

Re: 2018-03 CFM

[Thomas Munro]

On Sat, Mar 3, 2018 at 1:18 AM, Aleksander Alekseev
 wrote:
>> You do realize we have the actual source database available, I hope? Since
>> it's our own system... There is no need to scrape the data back out -- if
>> we can just define what kind of reports we want, we can trivially run it on
>> the source database. Or if we want it more often, we can easily make a
>> webview for it. It's basically just a "map this URL to a SQL query"...
>
> I don't think commitfest.cputube.org has the SQL data on whether patch
> pass the tests. It just displays SVG images from travis-ci.org. Also
> unfortunately both commitfest.postgresql.org and commitfest.cputube.org
> currently don't have any kind of public API and don't allow to export
> data, e.g. in CSV or JSON.
>
> I guess it would be nice if both services supported export, in any
> format, so anyone could build any kind of reports or automation tools
> without parsing HTML with regular expressions or depending on other
> people.
>
> If I'm not mistaken, there was a discussion regarding public APIs.
> I wonder what prevents adding it, at least a simple export of everything.
> After all, it is indeed just mapping URL to a SQL query. For instance,
> this one:
>
> select array_to_json(array_agg(row_to_json(tbl))) from tbl;

Hi Aleksander,

My current plan is to propose that we post automated apply/build
results into the Commitfest app itself so that it can show them, and
then shut down commitfest.cputube.org.  I don't have all the details
figured out yet and I won't be working on a proposal until after this
Commitfest is over.  If you have ideas on how it should receive, store
and show them, please clone the app (pgcommitfest2.git?) and start a
thread (maybe on pgsql-www?).  Here's a question for you to ponder:  I
think there should probably be one "apply" result (success/fail, and a
URL to find the log), but should there be one or many "build/test"
results?  It could show results from different OSes separately (Travis
macOS, Travis Ubuntu, AppVeyor Windows, ...), and it could track more
than one recent result (useful for seeing things that used to pass and
now fail or vice versa).

The reason commitfest.cputube.org is so limited, not integrated yet
and running on a strange domain name is because I decided to build an
independent proof-of-concept first.  I imagined that negotiating with
many busy people on how such a thing should work and what would even
be possible first would be more likely to stall, based on previous
experiences with humans :-D

-- 
Thomas Munro
http://www.enterprisedb.com

Re: 2018-03 CFM

[Stephen Frost]

Greetings,

* David Steele (da...@pgmasters.net) wrote:
> On 3/5/18 4:55 PM, Magnus Hagander wrote:
> > 
> > I would like to get a list of submitter patches totals vs the total
> > number of patches they are reviewing.  In the past I have done this by
> > eyeball.
> > 
> > I think that's pretty much the part that's available under "reports" to
> > use as CF manager? Link at the bottom of the CF page, reports -> Author
> > Stats?
> 
> Aha, I think I found that a long time ago and forgot about it.  Maybe it
> would be more obvious at the top of the page?
> 
> On my wishlist would be a way to mark that I looked at a patch (and
> maybe a comment), then be able to sort by that date.  Right now I'm
> keeping spreadsheets for that.

Agreed.  I ended up using "last email on this thread date" but that
isn't always quite the same.

I'd suggest a way to provide a couple of email addresses for that
though- in case we actually have a CFM + helpers.

Thanks!

Stephen


signature.asc
Description: PGP signature

Re: 2018-03 CFM

[David Steele]

Hi Magnus,

On 3/5/18 4:55 PM, Magnus Hagander wrote:
> 
> I would like to get a list of submitter patches totals vs the total
> number of patches they are reviewing.  In the past I have done this by
> eyeball.
> 
> I think that's pretty much the part that's available under "reports" to
> use as CF manager? Link at the bottom of the CF page, reports -> Author
> Stats?

Aha, I think I found that a long time ago and forgot about it.  Maybe it
would be more obvious at the top of the page?

On my wishlist would be a way to mark that I looked at a patch (and
maybe a comment), then be able to sort by that date.  Right now I'm
keeping spreadsheets for that.

Thanks,
-- 
-David
da...@pgmasters.net

Re: 2018-03 CFM

[Magnus Hagander]

On Mon, Mar 5, 2018 at 3:48 PM, David Steele  wrote:

> Hi Aleksander,
>
> On 3/2/18 7:18 AM, Aleksander Alekseev wrote:
> >
> >> You do realize we have the actual source database available, I hope?
> Since
> >> it's our own system... There is no need to scrape the data back out --
> if
> >> we can just define what kind of reports we want, we can trivially run
> it on
> >> the source database. Or if we want it more often, we can easily make a
> >> webview for it. It's basically just a "map this URL to a SQL query"...
> >
> > I don't think commitfest.cputube.org has the SQL data on whether patch
> > pass the tests. It just displays SVG images from travis-ci.org. Also
> > unfortunately both commitfest.postgresql.org and commitfest.cputube.org
> > currently don't have any kind of public API and don't allow to export
> > data, e.g. in CSV or JSON.
> >
> > I guess it would be nice if both services supported export, in any
> > format, so anyone could build any kind of reports or automation tools
> > without parsing HTML with regular expressions or depending on other
> > people.
>
> Yes, that would be good.  I just had a chance to look through the data
> and the thing I was most hoping to do with it would be a bit complicated.
>
> I would like to get a list of submitter patches totals vs the total
> number of patches they are reviewing.  In the past I have done this by
> eyeball.
>
>
I think that's pretty much the part that's available under "reports" to use
as CF manager? Link at the bottom of the CF page, reports -> Author Stats?


-- 
 Magnus Hagander
 Me: https://www.hagander.net/ 
 Work: https://www.redpill-linpro.com/ 

Re: 2018-03 CFM

[Aleksander Alekseev]

Hello David,

> I would like to get a list of submitter patches totals vs the total
> number of patches they are reviewing.  In the past I have done this by
> eyeball.
> 
> Do you think you could put something like that together?

Sure, no problem. It's pretty late in my timezone (UTC+3) right now
though so I'm going to make it tomorrow.

-- 
Best regards,
Aleksander Alekseev


signature.asc
Description: PGP signature

Re: 2018-03 CFM

[David Steele]

Hi Aleksander,

On 3/2/18 7:18 AM, Aleksander Alekseev wrote:
> 
>> You do realize we have the actual source database available, I hope? Since
>> it's our own system... There is no need to scrape the data back out -- if
>> we can just define what kind of reports we want, we can trivially run it on
>> the source database. Or if we want it more often, we can easily make a
>> webview for it. It's basically just a "map this URL to a SQL query"...
> 
> I don't think commitfest.cputube.org has the SQL data on whether patch
> pass the tests. It just displays SVG images from travis-ci.org. Also
> unfortunately both commitfest.postgresql.org and commitfest.cputube.org
> currently don't have any kind of public API and don't allow to export
> data, e.g. in CSV or JSON.
> 
> I guess it would be nice if both services supported export, in any
> format, so anyone could build any kind of reports or automation tools
> without parsing HTML with regular expressions or depending on other
> people.

Yes, that would be good.  I just had a chance to look through the data
and the thing I was most hoping to do with it would be a bit complicated.

I would like to get a list of submitter patches totals vs the total
number of patches they are reviewing.  In the past I have done this by
eyeball.

Do you think you could put something like that together?

> If I'm not mistaken, there was a discussion regarding public APIs.
> I wonder what prevents adding it, at least a simple export of everything.
> After all, it is indeed just mapping URL to a SQL query. For instance,
> this one:
> 
> select array_to_json(array_agg(row_to_json(tbl))) from tbl;

I would be happy with a page that is simply a json dump of the
publicly-viewable fields in each table.  Then I can do whatever I want
with the data.

Thanks,
-- 
-David
da...@pgmasters.net

Re: 2018-03 CFM

[Aleksander Alekseev]

Hello Magnus,

> You do realize we have the actual source database available, I hope? Since
> it's our own system... There is no need to scrape the data back out -- if
> we can just define what kind of reports we want, we can trivially run it on
> the source database. Or if we want it more often, we can easily make a
> webview for it. It's basically just a "map this URL to a SQL query"...

I don't think commitfest.cputube.org has the SQL data on whether patch
pass the tests. It just displays SVG images from travis-ci.org. Also
unfortunately both commitfest.postgresql.org and commitfest.cputube.org
currently don't have any kind of public API and don't allow to export
data, e.g. in CSV or JSON.

I guess it would be nice if both services supported export, in any
format, so anyone could build any kind of reports or automation tools
without parsing HTML with regular expressions or depending on other
people.

If I'm not mistaken, there was a discussion regarding public APIs.
I wonder what prevents adding it, at least a simple export of everything.
After all, it is indeed just mapping URL to a SQL query. For instance,
this one:

select array_to_json(array_agg(row_to_json(tbl))) from tbl;

-- 
Best regards,
Aleksander Alekseev


signature.asc
Description: PGP signature

Re: 2018-03 CFM

[Magnus Hagander]

On Fri, Mar 2, 2018 at 12:45 PM, Aleksander Alekseev <
a.aleks...@postgrespro.ru> wrote:

> > Hello David,
>
> > This data is worth cross-checking with http://commitfest.cputube.org/
> > though. For instance, the "Improve geometric types" patch doesn't apply.
> > I already notified the author. I'll try to write a script that exports
> > data from this site as well to make cross-checking easier.
>
> OK, I finished the second script and uploaded both scripts on GitHub
>

You do realize we have the actual source database available, I hope? Since
it's our own system... There is no need to scrape the data back out -- if
we can just define what kind of reports we want, we can trivially run it on
the source database. Or if we want it more often, we can easily make a
webview for it. It's basically just a "map this URL to a SQL query"...


-- 
 Magnus Hagander
 Me: https://www.hagander.net/ 
 Work: https://www.redpill-linpro.com/ 

Re: 2018-03 CFM

[Aleksander Alekseev]

> Hello David,

> This data is worth cross-checking with http://commitfest.cputube.org/
> though. For instance, the "Improve geometric types" patch doesn't apply.
> I already notified the author. I'll try to write a script that exports
> data from this site as well to make cross-checking easier.

OK, I finished the second script and uploaded both scripts on GitHub
[1]. Here is an updated report:

select left(cf.title, 64) as title, cf.url, cf.latest_mail
from commitfest as cf
left join cputube as ct on ct.url = cf.url
where status = 'Ready for Committer' and ct.apply_passing and ct.build_passing
order by latest_mail desc;


-[ RECORD 1 ]-
title   | Incorrect flag passed to initial_cost_hashjoin()
url | https://commitfest.postgresql.org/17/1551/
latest_mail | 2018-03-02 10:01:00
-[ RECORD 2 ]-
title   | Mention connection parameter "replication" in libpq section
url | https://commitfest.postgresql.org/17/1387/
latest_mail | 2018-03-02 09:44:00
-[ RECORD 3 ]-
title   | Fix tuple count during vacuum for partial GiST indexes
url | https://commitfest.postgresql.org/17/1483/
latest_mail | 2018-03-02 05:33:00
-[ RECORD 4 ]-
title   | Creating backup history files for backups taken from standbys
url | https://commitfest.postgresql.org/17/1231/
latest_mail | 2018-03-02 04:14:00
-[ RECORD 5 ]-
title   | New function for tsquery creation
url | https://commitfest.postgresql.org/17/1202/
latest_mail | 2018-03-02 03:06:00
-[ RECORD 6 ]-
title   | MCV lists for highly skewed distributions
url | https://commitfest.postgresql.org/17/1441/
latest_mail | 2018-03-01 22:26:00
-[ RECORD 7 ]-
title   | Surjective indexes
url | https://commitfest.postgresql.org/17/1152/
latest_mail | 2018-03-01 19:48:00
-[ RECORD 8 ]-
title   | pgbench - add \if support
url | https://commitfest.postgresql.org/17/1385/
latest_mail | 2018-03-01 18:06:00
-[ RECORD 9 ]-
title   | Fix LWLock degradation on NUMA
url | https://commitfest.postgresql.org/17/1166/
latest_mail | 2018-03-01 15:50:00
-[ RECORD 10 ]
title   | pg_proc.prokind column
url | https://commitfest.postgresql.org/17/1566/
latest_mail | 2018-03-01 00:46:00
-[ RECORD 11 ]
title   | Increase initdb's fallback value of max_connection to 20
url | https://commitfest.postgresql.org/17/1560/
latest_mail | 2018-02-28 18:11:00
-[ RECORD 12 ]
title   | UPDATE of partition key : Restrict concurrent update/delete
url | https://commitfest.postgresql.org/17/1368/
latest_mail | 2018-02-28 07:08:00
-[ RECORD 13 ]
title   | pg_rewind takes too long time to synchronize database cluster wi
url | https://commitfest.postgresql.org/17/1542/
latest_mail | 2018-02-28 06:58:00
-[ RECORD 14 ]
title   | Exclude unlogged tables from base backups
url | https://commitfest.postgresql.org/17/1409/
latest_mail | 2018-02-27 21:16:00
-[ RECORD 15 ]
title   | Vacuum: allow usage of more than 1GB of work mem
url | https://commitfest.postgresql.org/17/844/
latest_mail | 2018-02-19 21:50:00
-[ RECORD 16 ]
title   | Lockable views
url | https://commitfest.postgresql.org/17/1433/
latest_mail | 2018-02-06 16:12:00
-[ RECORD 17 ]
title   | Jsonb transform for pl/python
url | https://commitfest.postgresql.org/17/1400/
latest_mail | 2018-02-01 16:06:00
-[ RECORD 18 ]
title   | fix slot_store/modify_cstrings error callback bug in logical rep
url | https://commitfest.postgresql.org/17/1394/
latest_mail | 2018-01-31 01:38:00
-[ RECORD 19 ]
title   | General purpose hashing func in pgbench
url | https://commitfest.postgresql.org/17/1424/
latest_mail | 2018-01-29 12:55:00
-[ RECORD 20 ]--

Re: 2018-03 CFM

[Aleksander Alekseev]

Hello David,

> > Thank you for volunteering!
> > 
> > I would like to be CFM assistant, if you need one :)
> 
> Right now Andres and I are doing triage on the patches to determine what is
> likely to be committed in this CF.
> 
> I would be very interested in your input.  I generally start with patches
> that have had no email for the longest time and work my way down.  You can
> sort on the "Latest Mail" column in the CF app to help.

I wrote a script that exports commitfest data into PostgreSQL. You can
find the script and the data in the attachment to this email.

Here are open CF entries ordered by Latest Mail (first 10):

select title, url, latest_mail, status
from commitfest
where not (status = 'Committed' or status = 'Rejected' or
   status = 'Returned with feedback' or status = 'Moved to next CF')
order by latest_mail desc limit 10;

-[ RECORD 1 
]--
title   | GUC for cleanup index threshold
url | https://commitfest.postgresql.org/17/952/
latest_mail | 2018-03-02 07:53:00
status  | Needs review
-[ RECORD 2 
]--
title   | Changing the autovacuum launcher scheduling; oldest table first 
algorithm
url | https://commitfest.postgresql.org/17/1573/
latest_mail | 2018-03-02 07:51:00
status  | Needs review
-[ RECORD 3 
]--
title   | Boolean partition syntax
url | https://commitfest.postgresql.org/17/1410/
latest_mail | 2018-03-02 07:49:00
status  | Waiting on Author
-[ RECORD 4 
]--
title   | Online enabling of checksums
url | https://commitfest.postgresql.org/17/1535/
latest_mail | 2018-03-02 07:44:00
status  | Needs review
-[ RECORD 5 
]--
title   | autovacuum: add possibility to change priority of vacuumed tables
url | https://commitfest.postgresql.org/17/1519/
latest_mail | 2018-03-02 07:39:00
status  | Waiting on Author
-[ RECORD 6 
]--
title   | Early locking option to parallel backup
url | https://commitfest.postgresql.org/17/1367/
latest_mail | 2018-03-02 07:29:00
status  | Waiting on Author
-[ RECORD 7 
]--
title   | log_destination=file
url | https://commitfest.postgresql.org/17/1274/
latest_mail | 2018-03-02 07:27:00
status  | Needs review
-[ RECORD 8 
]--
title   | chained transactions
url | https://commitfest.postgresql.org/17/1594/
latest_mail | 2018-03-02 07:18:00
status  | Needs review
-[ RECORD 9 
]--
title   | Add support for ON UPDATE/DELETE actions on ALTER CONSTRAINT
url | https://commitfest.postgresql.org/17/1533/
latest_mail | 2018-03-02 07:15:00
status  | Needs review
-[ RECORD 10 
]-
title   | kNN for SP-GiST
url | https://commitfest.postgresql.org/17/1587/
latest_mail | 2018-03-02 06:35:00
status  | Needs review

However to find patches that will more likely be accepted in this CF I
believe we need to consider their status as well. For instance:

select title, url, latest_mail
from commitfest
where status = 'Ready for Committer'
  and (now() - latest_mail) < interval '7 days'
order by latest_mail desc limit 10;

-[ RECORD 1 
]--
title   | Fix tuple count during vacuum for partial GiST indexes
url | https://commitfest.postgresql.org/17/1483/
latest_mail | 2018-03-02 05:33:00
-[ RECORD 2 
]--
title   | Creating backup history files for backups taken from standbys
url | https://commitfest.postgresql.org/17/1231/
latest_mail | 2018-03-02 04:14:00
-[ RECORD 3 
]--
title   | New function for tsquery creation
url | https://commitfest.postgresql.org/17/1202/
latest_mail | 2018-03-02 03:06:00
-[ RECORD 4 
]--
title   | Improve geometric types
url | https://commitfest.postgresql.org/17/1160/
latest_mail | 2018-03-02 02:45:00
-[ RECORD 5 
]--
title   | Mention connection parameter "replication" in libpq 
section
url | https://commitfest.postgresql.org/17/1387/
latest_mail | 2018-03-02 01:50:00
-[ RECORD 6 
]

Re: 2018-03 CFM

[David Steele]

Hi Alexander,

On 2/27/18 5:05 AM, Aleksander Alekseev wrote:

Hello David,


Just a few days left until the last Commitfest for the PG11 release begins!

I'm planning to fill the CFM role, unless there are objections.


Thank you for volunteering!

I would like to be CFM assistant, if you need one :)


Right now Andres and I are doing triage on the patches to determine what 
is likely to be committed in this CF.


I would be very interested in your input.  I generally start with 
patches that have had no email for the longest time and work my way 
down.  You can sort on the "Latest Mail" column in the CF app to help.


I'll be working on this again in the morning, but I'm guessing you are 
6-7 hours earlier than me so if you have time in the morning have a 
look.  You can post your results to the list or send them to me.


However, at 09:00 ET I will be working again and we might overlap if you 
go into that time.


Thanks!
--
-David
da...@pgmasters.net

Re: 2018-03 CFM

[Aleksander Alekseev]

Hello David,

> Just a few days left until the last Commitfest for the PG11 release begins!
> 
> I'm planning to fill the CFM role, unless there are objections.

Thank you for volunteering!

I would like to be CFM assistant, if you need one :)

-- 
Best regards,
Aleksander Alekseev


signature.asc
Description: PGP signature

Re: 2018-03 CFM

[Michael Paquier]

On Mon, Feb 26, 2018 at 02:03:56PM -0500, Tom Lane wrote:
> David Steele  writes:
> > I'm planning to fill the CFM role, unless there are objections.
> 
> Thanks for volunteering!

+1.  I have also added a new commit fest entry marked as future, which
will likely be used for 12 development:
https://commitfest.postgresql.org/18/
2018-09 is a tentative name, please don't take that as a decided date as
this will be discussed in Ottawa during the dev meeting.

This matters for hackers as once a CF is marked as in-progress, there is
no way to register a patch in it.  And in the case of this March's CF,
there would be no places where such future patches could go.
--
Michael


signature.asc
Description: PGP signature

Re: 2018-03 CFM

[Tom Lane]

David Steele  writes:
> I'm planning to fill the CFM role, unless there are objections.

Thanks for volunteering!

regards, tom lane

2018-03 CFM

[David Steele]

Hackers,

Just a few days left until the last Commitfest for the PG11 release begins!

I'm planning to fill the CFM role, unless there are objections.

Regards,
-- 
-David
da...@pgmasters.net