Thread: 2018-03 CFM
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 david@pgmasters.net
David Steele <david@pgmasters.net> writes:
> I'm planning to fill the CFM role, unless there are objections.
Thanks for volunteering!
regards, tom lane
On Mon, Feb 26, 2018 at 02:03:56PM -0500, Tom Lane wrote: > David Steele <david@pgmasters.net> 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
Attachment
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
Attachment
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 david@pgmasters.net
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 ]----------------------------------------------------------------------
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 | Incorrect flag passed to initial_cost_hashjoin()
url | https://commitfest.postgresql.org/17/1551/
latest_mail | 2018-03-01 19:45:00
-[ RECORD 9 ]----------------------------------------------------------------------
title | pgbench - add \if support
url | https://commitfest.postgresql.org/17/1385/
latest_mail | 2018-03-01 18:06:00
-[ RECORD 10 ]---------------------------------------------------------------------
title | Fix LWLock degradation on NUMA
url | https://commitfest.postgresql.org/17/1166/
latest_mail | 2018-03-01 15:50:00
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.
If there is anything else I can help you with, just let me know.
--
Best regards,
Aleksander Alekseev
Attachment
> 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 ]---------------------------------------------------------------- title | XML XPath default namespace support url | https://commitfest.postgresql.org/17/1085/ latest_mail | 2018-01-29 09:01:00 -[ RECORD 21 ]---------------------------------------------------------------- title | Logical decoding of TRUNCATE url | https://commitfest.postgresql.org/17/1448/ latest_mail | 2018-01-28 16:01:00 -[ RECORD 22 ]---------------------------------------------------------------- title | Predicate locking in Gist index url | https://commitfest.postgresql.org/17/1172/ latest_mail | 2018-01-25 14:32:00 -[ RECORD 23 ]---------------------------------------------------------------- title | TRUNCATE behavior when session_replication_role = replica url | https://commitfest.postgresql.org/17/1447/ latest_mail | 2018-01-23 14:27:00 -[ RECORD 24 ]---------------------------------------------------------------- title | Failure at replay for corrupted 2PC files + reduce window betwee url | https://commitfest.postgresql.org/17/922/ latest_mail | 2018-01-13 22:13:00 -[ RECORD 25 ]---------------------------------------------------------------- title | Add NOWAIT option to VACUUM and ANALYZE url | https://commitfest.postgresql.org/17/1399/ latest_mail | 2018-01-11 02:17:00 -[ RECORD 26 ]---------------------------------------------------------------- title | pgbench - allow to store query results into variables url | https://commitfest.postgresql.org/17/669/ latest_mail | 2018-01-10 08:54:00 Raw data is attached. [1]: https://github.com/afiskon/py-autoreviewer -- Best regards, Aleksander Alekseev
Attachment
On Fri, Mar 2, 2018 at 12:45 PM, Aleksander Alekseev <a.alekseev@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"...
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
Attachment
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 david@pgmasters.net
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
Attachment
On Mon, Mar 5, 2018 at 3:48 PM, David Steele <david@pgmasters.net> 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?
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 david@pgmasters.net
Greetings, * David Steele (david@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
Attachment
On Sat, Mar 3, 2018 at 1:18 AM, Aleksander Alekseev <a.alekseev@postgrespro.ru> 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
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 david@pgmasters.net
On Tue, Mar 6, 2018 at 1:00 PM, David Steele <david@pgmasters.net> 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
On 3/5/18 8:33 PM, Thomas Munro wrote: > On Tue, Mar 6, 2018 at 1:00 PM, David Steele <david@pgmasters.net> 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 david@pgmasters.net
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 <david@pgmasters.net> 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
Hi, Michael! > 27 февр. 2018 г., в 6:34, Michael Paquier <michael@paquier.xyz> написал(а): > > On Mon, Feb 26, 2018 at 02:03:56PM -0500, Tom Lane wrote: >> David Steele <david@pgmasters.net> 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. Maybe CF should be open if 2018-03 is in progress? Best regards, Andrey Borodin.
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
Attachment
> 7 марта 2018 г., в 12:00, Michael Paquier <michael@paquier.xyz> написал(а): > > 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.