19:01:22 <wumpus> #startmeeting
19:01:22 <lightningbot> Meeting started Thu Jun 13 19:01:22 2019 UTC.  The chair is wumpus. Information about MeetBot at http://wiki.debian.org/MeetBot.
19:01:22 <lightningbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
19:01:32 <cfields> hi
19:01:37 <dongcarl> hi (sort of)
19:01:41 <achow101> hi
19:01:48 <meshcollider> hi
19:01:51 <wumpus> #bitcoin-core-dev Meeting: wumpus sipa gmaxwell jonasschnelli morcos luke-jr sdaftuar jtimon cfields petertodd kanzure bluematt instagibbs phantomcircuit codeshark michagogo marcofalke paveljanik NicolasDorier jl2012 achow101 meshcollider jnewbery maaku fanquake promag provoostenator aj Chris_Stewart_5 dongcarl gwillen jamesob ken281221 ryanofsky gleb moneyball kvaciral
19:02:10 <phantomcircuit> hi
19:02:40 <wumpus> we have three topics in https://gist.github.com/moneyball/071d608fdae217c2a6d7c35955881d8a
19:02:51 <moneyball> hi
19:02:57 <phantomcircuit> sipa, oh it's the bloom filters that add other stuff
19:03:02 <sipa> topic suggestion: ASN database shipped with bitcoind?
19:03:29 <wumpus> also high priority for review but I didn't look at that at all this week due to coredev and the conference tbh
19:03:42 <phantomcircuit> sipa, i think yes, it's certainly better than assuming /16 are distinct entities
19:03:49 <jb55> sipa: can you go over the benefit of that for those who might be out of the loop
19:03:52 * jb55 like this guy
19:03:57 <wumpus> #topic High priority for review
19:04:06 <sipa> phantomcircuit, jb55: i'm suggesting a topic; we'll discuss it when the topic comes up
19:04:26 <Chris_Stewart_5> hello
19:04:27 <wumpus> https://github.com/bitcoin/bitcoin/projects/8 there's four things on there now
19:04:40 <wumpus> +2 brainstorming topics
19:05:18 <wumpus> anything to add/remove for this week ?
19:05:36 <MarcoFalke> I'd like to add #14193
19:05:40 <gribble> https://github.com/bitcoin/bitcoin/issues/14193 | validation: Add missing mempool locks by MarcoFalke · Pull Request #14193 · bitcoin/bitcoin · GitHub
19:05:52 <sipa> not sure to what extent we decided that the high priority list should have an implicit "basic concept ack" because discussed in the meeting; but to the extent that it is, i think the list entries are great :)
19:06:03 <MarcoFalke> good point
19:06:15 <MarcoFalke> I'd like to add 14193 as "bugfix"
19:06:35 <jtimon> review beg https://github.com/bitcoin/bitcoin/pull/8994#issuecomment-501826862
19:06:55 <wumpus> missing locks sounds pretty concept ackable
19:07:04 <MarcoFalke> jtimon: are you adding that as "Chasing Concept ACK"?
19:07:20 <MarcoFalke> wumpus: Yeah, it has been open for months and hasn't received any attention
19:07:30 <fanquake> dongcarl do you have any build related blockers? Guix or otherwise.
19:07:32 <sipa> concept ack
19:08:21 <meshcollider> concept ack for adding Marco's PR
19:08:34 <dongcarl> fanquake: looking
19:08:47 <sipa> agree on jtimon
19:08:52 <sipa> agree on jtimon's pr as chasing concept ack
19:08:56 <jnewbery> I'd like #16060 on there. I have a couple of review comments from last week to address. It's blocking some work that BlueMatt is doing on reducing cs_main usage
19:08:59 <gribble> https://github.com/bitcoin/bitcoin/issues/16060 | Bury bip9 deployments by jnewbery · Pull Request #16060 · bitcoin/bitcoin · GitHub
19:09:06 <wumpus> why is the github 'add cards' search so broken, every time I search for a number it shows 20 different ones
19:09:33 <jonasschnelli> yes. that's so broken
19:09:46 <jnewbery> wumpus: I think it's easier to add a PR to a project from within the PR itself
19:09:47 <dongcarl> fanquake: no blockers
19:10:36 <fanquake> Yes from the sidebar in a PR is usually easy.
19:10:37 <jtimon> MarcoFalke: yeah, I mean, it got concept acks before, but I have been not rebasing it for 6 months or so
19:10:53 <fanquake> dongcarl ok
19:11:25 <wumpus> jnewbery: good point
19:11:35 <jtimon> I think 16060 could be done before or after and I think the result will be the same
19:11:36 <jb55> jnewbery jtimon: testchains pr would be good for review club?
19:12:43 <fanquake> I’m no more High Priority, should we discuss first proposed topic? EOL dates?
19:12:43 <jtimon> jb55: sure, why not?
19:13:08 <wumpus> #topic Update EOL dates (MarcoFalke)
19:13:18 <wumpus> https://github.com/bitcoin-core/bitcoincore.org/pull/659#issuecomment-499884131
19:13:30 <instagibbs> how do I read those columns in isolation?
19:13:50 <kanzure> hi
19:14:07 <MarcoFalke> Basically I am removing historical EOL dates and update others
19:14:15 <cfields> Would it be possible to pull these values from SECURITY.md, rather than keeping them in sync?
19:14:16 <achow101> is it necessary to remove historical ones?
19:14:28 <wumpus> LGTM
19:14:41 <MarcoFalke> achow101: They are not representative and have been made up
19:14:44 <wumpus> it defeinitely cleans up a lot
19:15:10 <MarcoFalke> The only information you need is that they are surely eol today
19:15:17 <wumpus> yes
19:15:33 <meshcollider> Is it sensible to add an EOL date for 0.17 before the maintainance end date has even been announced
19:15:49 <wumpus> for the rest there's git history I guess…
19:16:04 <wumpus> but come on, 0.8.x
19:16:08 <MarcoFalke> meshcollider: good point
19:16:25 <wumpus> meshcollider:probably not
19:16:30 <MarcoFalke> I think given that we have a fixed release schedule, it should be fine
19:16:45 <cfields> wumpus: segwit 0.8.x when? :p
19:16:47 <achow101> perhaps put the scheduled 0.19 release date?
19:16:50 <wumpus> things drift a few months here and there though
19:16:54 <wumpus> cfields:lol
19:16:55 <achow101> (for 0.17 maintenance end)
19:17:38 <MarcoFalke> happy to remove the 0.17 EOL, though
19:18:00 <instagibbs> (took me way too long to figure out the table headers: https://bitcoincore.org/en/lifecycle/#schedule )
19:18:10 <meshcollider> the EOL date for 0.16 seems fine though, just under 1 year was the rule I used last time I updated it
19:18:17 <cfields> Again, though, can we somehow automatically keep this in sync with SECURITY.md? I'm afraid of them drifting apart.
19:18:19 <wumpus> yes
19:19:20 <fanquake> We could just make security.md the place where they live, and they get manually/automatically pulled out of their for website updates?
19:19:28 <meshcollider> +1
19:19:31 <wumpus> so the information in security.md is only for security fixes, not general maintenance
19:19:59 <wumpus> it should list the versions that are not entirely EOL I guess
19:20:14 <cfields> fanquake: +1
19:20:15 <meshcollider> Kinda makes more sense to have it in the repo though than on a separate website?
19:20:45 <wumpus> maybe ...
19:20:57 <wumpus> I'm usually not in favor of importing everything into the repo
19:21:05 <achow101> it should be possible to have SECURITY.md fetched and parsed during the build for the website. I know bitcoin.org does something similar to generate the contributors page
19:21:14 <nehan> fwiw: the motivation for SECURITY.md was in part because people who wanted to report things did not know about bitcoincore.org
19:21:23 <wumpus> like it's fiiine to maintain different things in different places, it doesn't all have to go through the same bottleneck you know
19:21:39 <wumpus> nehan: yes, for reporting it makes perfect sense
19:21:45 <sipa> i think the SECURITY.md living in the repo itself is weird, as it's not tied to the specific source tree it lives in (this is also true for release notes etc)
19:21:50 <MarcoFalke> Add it to "release-process.md"? *ducks
19:21:53 <meshcollider> Fair enough actually yeah
19:22:28 <MarcoFalke> sipa: Release notes should be shipped, so at least during build you'd have to fetch them
19:22:29 <wumpus> sipa: I think the reporting emails and gpg keys are
19:22:36 <cfields> sipa: elaborate?
19:22:43 <wumpus> sipa: as for the schedule, I guess I'd somewhat agree
19:23:01 <sipa> cfields: which versions are still under maintenance, eg
19:23:28 <wumpus> but that wasn't the main point of security.md, it was to let people know where to report critical security issues
19:23:51 <fanquake> security.md is also being removed from any branch that isn’t master right.
19:23:53 <sipa> if someone randomly clones the repo, leaves their copy untouched for years... someone stumbles upon it (like nkohen's with roasbeef's repo above ^), and sees the version they think they
19:23:53 <wumpus> and I guess what releases to report them for ? like, if you find a problem with 0.8 now it's probably not useful to report it
19:23:55 <MarcoFalke> So lets remove the eol dates from there again?
19:23:58 <sipa> if someone randomly clones the repo, leaves their copy untouched for years... someone stumbles upon it (like nkohen's with roasbeef's repo above ^), and sees the version they think they're working with is maintained
19:24:08 <cfields> wumpus: fair enough.
19:24:35 <sipa> i don't know if this confusion doesn't weigh up to having the information in a well-visible location
19:24:38 <cfields> MarcoFalke: I'd +1 that as well. I just don't like the idea of having them maintained separately in two places.
19:24:44 <wumpus> sipa: yes
19:24:57 <wumpus> ok, let's remove the dates from security.md
19:25:08 <MarcoFalke> #action remove the dates from security.md
19:25:20 <sipa> we could have a link in security.md to the authoritative place where that information is maintained
19:25:22 <instagibbs> ack
19:25:33 <meshcollider> +1
19:25:33 <fanquake> If that’s done. Second proposed topic is where to have the next Core Dev meetup.
19:25:43 <cfields> sipa: +1
19:25:50 <moneyball> hi
19:25:55 <MarcoFalke> ok,next topic
19:25:57 <wumpus> #topic when/where should we have next CoreDev? (moneyball)
19:26:02 <moneyball> Thanks for those that attended CoreDev. By all accounts I think it was a success!
19:26:07 <wumpus> agree!
19:26:10 <MarcoFalke> Once per release seems fine to me
19:26:13 <moneyball> We had 18 responses to the feedback survey. The summary is "don't change anything." 72% want to keep reviewing/merging unstructured. 93% liked the scheduled talks. 83% think 3 days is the optimal duration. And majority of people like the # attendees and the mix.
19:26:13 <meshcollider> Definitely, thank you \i/
19:26:19 <cfields> moneyball: thanks for organizing!
19:26:27 <moneyball> If anyone has other feedback please either fill out the form or let schmidty or me know.
19:26:31 <instagibbs> I definitely think it was the best so far
19:26:40 <jonasschnelli> Yeah. Thanks moneyball!
19:26:46 <sipa> indeed!
19:26:50 <fanquake> \o/
19:27:05 <sipa> also congrats on getting Gary fired
19:27:19 <moneyball> thx :)
19:27:24 <moneyball> So I started thinking about the next CoreDev already! Aiming for 6-9 months from now which means December to March. Considerations include, most importantly, what % of active Core devs can attend, and after that, minimizing aggregate travel time/timezone shift/cost of travel, exploring new locations, winter weather, ease of organizing (eg piggyback off of conferences or have local Core devs to help)
19:27:26 <jonasschnelli> indeed. Congratz moneyball
19:27:38 <MarcoFalke> Who is gary?
19:27:45 <cfields> moneyball: since there's typically a large turnout for Financial Crypto, maybe we could piggyback there?
19:27:52 <cfields> It's usually within that window.
19:27:58 <wumpus> not December please :)
19:28:02 <moneyball> Initial candidates include SF, Austin, NYC, Uruguay mid-December (La Bitconf), and Australia (possible Feb 2020 Bitcoin conf). If anyone has other candidate dates/locations please let me know! I'll likely send a survey around (sorry for all the surveys but it is really helpful!) allowing Core devs to rank candidate locations.
19:28:05 <instagibbs> internet kinda really sucks there cfields IIRC
19:28:07 <jonasschnelli> We haven't had a CoreDev in Hawaii...
19:28:08 <nehan> moneyball: also MIT Bitcoin Expo
19:28:12 <fanquake> Marco A fake SquareCrypto intern.
19:28:56 <MarcoFalke> Ah, thx. I uninstalled twitter
19:29:01 <moneyball> nehan i will add that to the list!
19:29:16 <instagibbs> Holiday season is a prob a no-go, as wumpus said.
19:29:24 <sipa> cfields: i'd personally like a coredev colocated with FC, but i'm not sure it's that accessible for everyone (especially people who don't have company funding for travel)
19:29:42 <jnewbery> financial crypto is 5 days. piggybacking would make a very long trip for people
19:29:54 <cfields> sipa: good point.
19:29:57 <achow101> moneyball: there's also advancing bitcoin in london in feb
19:30:04 <instagibbs> co-located to another less-academic conference also has the benefits of people can submit talks/run workshops and piggyback that
19:30:25 <jonasschnelli> coredev.tech does fund travel expenses of those not receiving support from employers
19:30:25 <sipa> about Boston: not everyone can enter (or likes to enter) the US
19:30:37 <fanquake> I’d probably almost strike Aus of the list for Dec - Feb. Too hot.
19:31:17 <sipa> fanquake: i was very confused for a minute and thought you were talking about austin
19:31:17 <instagibbs> dropbears don't like the heat though
19:31:43 <jnewbery> fanquake: maybe in Binnu. There are places that aren't quite as hot
19:31:48 <fanquake> Yes but neither do Core Devs I’d assume.
19:32:16 <fanquake> jnewbery if your happy with 40C days, go ahead. We’ll have Core dev on the beach.
19:32:38 <meshcollider> NZ is a bit more mild than aus, come over here instead ;)
19:32:42 <jnewbery> I meant maybe Binnu was too hot and we could have it somewhere else
19:32:43 <wumpus> hehe
19:33:07 <fanquake> ah right
19:33:08 * sipa would suggest Iceland (nicely in the middle between EU and US), but only if in summer :)
19:33:08 <moneyball> regarding not wanting to enter the US, i would like to better understand how big of an issue this is. if those affected are comfortable, please reach out to me and let me know so it is taken into account
19:33:26 <wumpus> Iceland :D
19:33:34 <jonasschnelli> ack Iceland
19:33:36 <instagibbs> there are >=2 people that came to last coredev that can't come generally speaking.
19:33:47 <moneyball> yeah the next next CoreDev is already decided...summer 2020 iceland :)
19:33:49 <nehan> i was also going to suggest iceland
19:34:07 <instagibbs> It should be over the next halving tbh :)
19:35:09 <fanquake> moneyball I think this could be left for suggestions/comments. Anything else you wanted to bring up? Otherwise final proposed topic is Travis instability.
19:35:24 <moneyball> all good thanks for the input everyone
19:35:52 <meshcollider> Is there a way to provide input that's easier for you? Like a survey of our preferred location and timing or something?
19:36:04 <cfields> moneyball: fyi, the last thing done at FC is voting on the next location. Which is cool because the people there are obviously a great sample.
19:36:11 <cfields> Just throwing that out there because I think it's neat :)
19:36:26 <sipa> it's just an informative vote though; the actual decision is made much later
19:36:35 <cfields> right, that.
19:36:48 <wumpus> heh it doesn't include the people that weren't able to come
19:36:58 <meshcollider> Confirmation bias lol
19:37:02 <sipa> self-echochambering is best echochambering
19:37:12 <wumpus> #topic Travis stability and usefulness in current state (jonasschnelli)
19:37:35 <wumpus> travis is failing sooo much on PRs now
19:37:43 <moneyball> i'll do a survey ranking locations
19:37:47 <jonasschnelli> We probably discussed that already to a certain level. But somehow I think we should have a plan how to get travis back on track
19:38:05 <jonasschnelli> Right now on an avg of 3-4 tries travis will succeed.
19:38:16 <wumpus> it's absurd that even PRs that change like 3 comment lines fail
19:38:19 <cfields> jonasschnelli: by travis do you mean Travis the service? Or our c-i checks in general?
19:38:38 <wumpus> I know it's bad but I'm already starting to effectively ignore it
19:38:39 <jonasschnelli> It can't be that we just need to re-trigger builds all over... this makes the value of CI partially disappearing
19:39:07 <fanquake> cfields: it seems like lots of invalide caches, casting constant depends rebuilds? At least what I’ve seen.
19:39:09 <wumpus> it used to be 'oh this PR fails, it needs more work by the author' but it's never the author's fault !
19:39:21 <fanquake> *invalid, *causing
19:39:32 <wumpus> so I run the tests locally, which is incomplete but at least reliable ...
19:39:41 <achow101> can drahtbot be made to retrigger travis on certain kinds of errors?
19:39:42 <jonasschnelli> I think we should have a strategy how to escape this mess...
19:39:52 <achow101> otherwise maybe we should consider using a different CI
19:40:03 <jonasschnelli> eventually... but that is a lot of work
19:40:03 <fanquake> The depends builds then obviously take up all the build time, and the build dies.
19:40:11 <wumpus> yes, we need something better
19:40:13 <cfields> Maybe we should finally consider decoupling the depends builds?
19:40:17 <wumpus> another CI would be ok with me
19:40:23 <jb55> circle-ci ?
19:40:31 <sipa> are there any self-hostable CI systems that integrate with github?
19:40:58 <cfields> (afaik I've been the one arguing for keeping depends compiles included in the past, but things have changed...)
19:41:02 <wumpus> I liked travis a lot when it worked but this is just not doable anymore
19:41:07 <jonasschnelli> I think it would be worth if willing people can propose a researched alternative on next meeting
19:41:27 <wumpus> cfields: you mean, using distro deps instead of depends?
19:41:32 <fanquake> I think those would be interesting to review.
19:41:33 <jonasschnelli> if we have volunteers...
19:41:44 <wumpus> cfields: too bad travis has such old versions
19:41:52 <meshcollider> sipa: Jenkins is self hostable I think
19:41:55 <wumpus> it's still trusty isn't it?
19:42:01 <cfields> wumpus: I mean automating depends builds separately, and having bitcoind builds fetch pre-built depends binaries.
19:42:09 <wumpus> cfields: ohh makes sense
19:42:20 <wumpus> cfields: then only do depends rebuilds, if depends change
19:42:21 <fanquake> FYI if anyone is unaware, we already have a circle CI confit in the repo, and Marco runs its against his own repo I’m pretty sure. Has a PR open for confit updates atm.
19:42:27 <cfields> as that seems to be the biggest mess?
19:42:30 <jonasschnelli> github lists 24 CI tools: https://github.com/marketplace/category/continuous-integration
19:42:38 <wumpus> cfields: it's certainly speed up things a lot
19:42:42 <wumpus> it'd*
19:42:59 <wumpus> especially the qt build in depends takes a long time, the rest is pretty fast
19:43:07 <cfields> I can work on that if it sounds interesting?
19:43:13 <cfields> It would introduce some new sync issues...
19:43:24 <cfields> But may be better than the status quo.
19:43:29 <wumpus> protobuf is a few seconds, even boost is, as we've stripped it down a lot
19:43:41 <wumpus> but qt....
19:43:46 <fanquake> cfields: would the pre built stuff live on bitcoincore.org ?
19:43:47 <cfields> I think it probably takes longer to gzip boost than to build it :(
19:43:52 <wumpus> yes
19:43:57 <sipa> cfields: lol
19:44:05 <wumpus> I think so too hehe
19:44:23 <wumpus> so it *seems* that travis caching is not working anymore
19:44:30 <wumpus> it rebuilds things unnecessarily a lot
19:44:33 <cfields> fanquake: I guess so?
19:44:41 <jonasschnelli> Maybe Google Cloud Builds could be something? Supported by Github?
19:44:46 <cfields> wumpus: the problem would be when you need a new dependency for your core change.
19:44:55 <cfields> Might have to split that up logically and wait a day for sync.
19:44:57 <wumpus> it shouldn't need to rebuild the depends on a PR that changes three comment lines, if the branch has the same version of depends
19:45:05 <cfields> s/new/modified/
19:45:35 <fanquake> I’m just slightly worried about the potential lag in updates. Especially as a lot of build related work is happening atm.
19:45:57 <instagibbs> could there be a "no really, build depends" option somehow?
19:45:59 <cfields> fanquake: that's probably a good bit of what's making the build times worse, though.
19:46:01 <wumpus> anything is better than having travis fail on every pr
19:46:09 <cfields> Any touch to depends will mean that tons of PRs start rebuilding everything.
19:46:12 <fanquake> cfields: true
19:46:35 <wumpus> cfields: ohh of course
19:46:44 <wumpus> would make sense to decouple it
19:47:12 <cfields> I'll take a look at that in parallel to the discussion about other services.
19:47:19 <wumpus> thanks
19:47:20 <jonasschnelli> Would asking the Travis guys be an option (explain them our situation)?
19:47:29 <jonasschnelli> I guess its mostly about execution time limits
19:47:36 <cfields> I'm also not opposed to self-hosted as I was before. The landscape has changed. We have lots more volunteers now :)
19:48:01 <fanquake> Does that mean your volunteering :p
19:48:14 <cfields> fanquake: nobody would want that :p
19:48:16 <wumpus> I used to be oppposed to self-hosted, but if hosted CIs are this bad, anything is better :p
19:48:17 <fanquake> Need to use the big new desktop for something hah.
19:48:25 <jonasschnelli> Travis would still be fine if we add self-hosted Jenkins... if we strip the depends build on the travis side
19:48:46 <jb55> #bitcoin-builds would be a good place to coordinate build system/ops stuff
19:49:15 <instagibbs> this channel is really not that busy...
19:49:35 <wumpus> hehe I'm still sceptical about the channel split too, though it's cosy there
19:49:47 <jb55> yeah just mentioning it since it's already there
19:50:03 <fanquake> So conclusion is some options might be presented at the next meeting? There are no more proposed topics left.
19:50:10 <cfields> * instagibbs has been banned from #bitcoin-builds
19:50:22 <instagibbs> psh like I was ever going there
19:50:32 <wumpus> hehe
19:50:44 <fanquake> sipa did you want to discuss the ASN stuff?
19:50:48 <sipa> sure
19:50:54 <sipa> though it's probably better if BlueMatt is here
19:51:06 <wumpus> oh sorry forgot about sipa's topic a bit
19:51:54 <fanquake> Can someone at chaincode tap Matt on the shoulder. jamesob ?
19:51:56 <wumpus> oh in that case let's add it to proposed topics for next week, and hope BlueMatt is there then
19:52:31 <sipa> all right
19:53:13 <wumpus> thanks everyeone
19:53:17 <wumpus> #endmeeting