19:00:21 <wumpus> #startmeeting
19:00:21 <lightningbot> Meeting started Thu Aug 15 19:00:21 2019 UTC.  The chair is wumpus. Information about MeetBot at http://wiki.debian.org/MeetBot.
19:00:21 <lightningbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
19:00:34 <provoostenator> hi
19:00:41 <jonasschnelli> hi
19:00:44 <MarcoFalke> (In theory, in practice `apt update` times out ...)
19:00:46 <MarcoFalke> hi
19:01:05 <wumpus> yes, that's nice, hopefully the theory starts working out :)
19:01:06 <real_or_random> hi
19:01:22 <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:01:37 <wumpus> no proposed topics on the weekly meeting list
19:01:41 <cfields> MarcoFalke: I wasn't here last week to post, but here was my feedback for Github: https://pastebin.com/raw/3PS5rtdN
19:01:42 <sipa> hi
19:01:46 <MarcoFalke> But the good news is that the ci can be run locally (or anywhere now). See ./ci/ subfolder
19:01:56 <jonasschnelli> nice
19:02:00 <gleb> hi
19:02:05 <Chris_Stewart_5> hi
19:02:11 <sipa> MarcoFalke: nice
19:02:12 <cfields> Glad to see you're trying it out, though :)
19:02:42 <jonasschnelli> Though I still not fully buying into the concept that a CI configuration should be part of the main repository
19:02:42 <wumpus> right, at least we know its limitations now, thanks!
19:02:46 <MarcoFalke> cfields: Yeah, I guess in the end we'll go with jonasschnelli's ci
19:03:04 <jonasschnelli> (once it's mature enough)
19:03:05 <ryanofsky> fun fact: the ci folder contains 4 mentions of the word "poop"
19:03:08 <MarcoFalke> jonasschnelli: Why not? travis.yml is part of the main repo
19:03:22 <achow101> hi
19:03:32 <jonasschnelli> Just conceptually I don't understand why the CI configuration needs to be part of the project sources
19:03:40 <jonasschnelli> Could be another repo, config-file, whatever
19:03:45 <jnewbery> hi
19:04:01 <MarcoFalke> jonasschnelli: Because the config needs to be updated atomically with the source code
19:04:09 <jonasschnelli> why?
19:04:23 <MarcoFalke> Let's say I add a new dependency boost-process, the ci runner needs to install it
19:04:54 <jonasschnelli> Yes. But it could be update in that secondary config file / repository then
19:05:19 <MarcoFalke> And in the meantime the ci couldn't run?
19:05:26 <MarcoFalke> Also you couldn't run it on older branches
19:05:34 <jonasschnelli> Maybe...
19:05:55 <jonasschnelli> It just feels this would not scale with multiple build systems / CI
19:06:09 <jonasschnelli> With the Appvayor, it's already a problem IMO
19:06:20 <jonasschnelli> but I'm probably complicating things...
19:06:26 <MarcoFalke> My plan was to only have one place to put the config and have all build systems use that config
19:06:44 <MarcoFalke> I tested it with GitHub CI, Cirrus CI, Travis CI. They all use the same config and it works
19:06:57 <jonasschnelli> Wouldn't that lead to a monotonic CI/test system?
19:07:25 <MarcoFalke> It includes the whole build matrix. But I agree
19:07:28 <kanzure> hi
19:07:33 <ryanofsky> i think it's convenient for things like ci and lint to be in the main repository, it would be a headache to have a change like #16367 that requires a ci update and have to stage it in multiple prs
19:07:36 <gribble> https://github.com/bitcoin/bitcoin/issues/16367 | Multiprocess build support by ryanofsky · Pull Request #16367 · bitcoin/bitcoin · GitHub
19:07:51 <jonasschnelli> My understanding would be, that there are a bunch of test-systems (call it CIs), running aside of our repo...
19:07:56 * dongcarl enjoyed ryanofsky's fun fact
19:08:13 <jonasschnelli> They have all their custom setup to test various configurations
19:08:21 <provoostenator> I'd like to be able to run CI without Docker at some point...
19:08:27 <jonasschnelli> If we run the same matrix on all CIs,.. seems a bit pointless
19:08:40 <MarcoFalke> jonasschnelli: Right. Agree on that
19:08:40 <jonasschnelli> provoostenator: bitcoinbuilds at least runs without docker...
19:08:55 <MarcoFalke> It is more a plan to not be married to one CI supplier
19:08:57 <wumpus> dongcarl: same :)
19:09:04 <jonasschnelli> which is a good point. If we have one CI script that always runs in docker...
19:09:31 <MarcoFalke> provoostenator: jonasschnelli: You can also run ./ci/ without docker
19:09:38 <MarcoFalke> Though that messes up the host (obviously)
19:10:10 <jonasschnelli> Okay. Let me continue to think about this... but I see the point of convenience
19:10:25 <provoostenator> Right, it would be happy to run just one specifiic host
19:10:53 <provoostenator> E.g. I have a Bionic x86 machine here, or an ARM machine elsewhere.
19:11:05 <MarcoFalke> jonasschnelli: Yeah let's continue in #bitcoin-builds or in one of my follow up pull requests that I plan to open soon :)
19:11:09 <jonasschnelli> ack
19:11:18 <sipa> proposed topic: libsecp256k1 maintenance
19:11:33 <MarcoFalke> #topic libsecp256k1 maintenance (sipa)
19:12:12 <sipa> so, lately i haven't had too much time to deal with maintaining libsecp256k1
19:12:29 <sipa> and also the other existing maintainers haven't been active
19:13:28 <sipa> real_or_random has been pretty active, and i'd like to transition to giving him maintainer rights
19:13:29 * jonasschnelli looks at real_or_random
19:13:47 <sipa> but i wanted to bring this up here, as the secp256k1 repo is under the bitcoin-core org
19:13:48 <MarcoFalke> I was about to suggest the first one to say a word will become the next maintainer
19:14:02 <real_or_random> glad I haven't said a word
19:14:04 <instagibbs> congrats... jonasschnelli ;P
19:14:12 <MarcoFalke> good to hear that real_or_random is volunteering for that position
19:14:15 <jonasschnelli> ack on real_or_random
19:14:33 <jonasschnelli> instagibbs: that was just an irc-action.. :P
19:14:59 <wumpus> I'd like to volunteer but currently, I'm just not able to
19:15:51 <MarcoFalke> wumpus: We should make a rule that Bitcoin Core maintainers are not allowed to maintain other projects :)
19:15:56 <nickler> ack real_or_random
19:16:03 <real_or_random> I think nickler was volunteering too :)
19:16:05 <wumpus> MarcoFalke: that's okay with me too :)
19:16:09 <provoostenator> also ack real_or_random
19:16:20 <MarcoFalke> ack nickler and real_or_random
19:16:26 <wumpus> *leaves bitcoin core for secp256k1* hehe
19:16:26 <sipa> also ack nickler from me, obviously :)
19:16:30 <jonasschnelli> also ack nickler
19:16:52 <sipa> that was easy.
19:16:53 <nickler> I'd be happy to help
19:16:56 <instagibbs> should people be removed?
19:17:05 <instagibbs> or is it just too small a number
19:17:21 <jonasschnelli> I guess greg and sipa?
19:17:28 <provoostenator> nickler what's your Github name?
19:17:34 <jonasschnelli> Fine for me to keep it for now
19:17:37 <sipa> it's andytoshi and me
19:17:37 <nickler> provoostenator: jonasnick
19:17:40 <sipa> currently
19:17:49 <provoostenator> Ah ok, ACK
19:17:56 <instagibbs> ok ACK
19:18:03 <wumpus> are you going to add them sipa or should I?
19:18:20 <sipa> i will.
19:18:22 <MarcoFalke> Is it that repo: https://github.com/bitcoin-core/secp256k1 ?
19:18:26 <sipa> correct
19:18:30 <wumpus> yes
19:18:37 <jonasschnelli> I think removing is something that could be done after 1y of inactivity or if someone explicitly wants to be removed
19:18:39 <MarcoFalke> why is the latest merge not signed and done with GitHub?
19:18:55 <MarcoFalke> (ot)
19:19:28 <jonasschnelli> valid point... some merge policy would probably be wise
19:19:30 <sipa> we should probably add merge checks in CI just like in bitcoin core itself
19:19:31 <real_or_random> MarcoFalke: yeah I think there are a few related issues to  discuss
19:19:34 <provoostenator> Could reuse some of the Bitcoin Core tools over?
19:19:38 <sipa> yeah.
19:19:53 <real_or_random> also e.g., I have an open issue about a security.md file
19:20:34 <real_or_random> which raises the question who should be in there. secp256k1 maintainers or bitcoin-core maintainers?
19:20:50 * MarcoFalke has set a bash alias `ghm` for "github-merge.py" that works on any repo
19:21:08 <real_or_random> and we also don't have super clear guidelines for what should be in the repo and what not (e.g., we have the JNI bindings that we may want to remove)
19:21:08 <wumpus> we should probably move github-merge.py to maintainer-tools
19:21:17 <wumpus> instead of having it in the bitcoin core repository
19:21:46 <wumpus> that way it's much easier to use it for different projects
19:21:56 <sipa> i think that libsecp256k1 issues which don't directly affect bitcoin core can be kept inside the secp256k1 project (bitcoin core has no need for JNI... :p)
19:22:22 <sipa> and discussed on the #secp256k1 channel
19:22:24 <wumpus> secp256k1 issues should probably be reported to secp256k1 maintainers, in general
19:22:51 <sipa> agree; though very serious issues that impact bitcoin could of course also be reported to bitcoin core
19:23:09 <real_or_random> wumpus: yes this seems sensible they can escalate to core if necessary
19:23:30 <sipa> wumpus: agree on moving over github-merge to maintainer-tools
19:23:40 <sipa> i use it for unrelated projects too :)
19:23:44 <wumpus> yes, if it affects use in bitcoin, or is even an issue that threatens bitcoin, that seems an exception
19:24:21 <wumpus> sipa: ok!
19:24:41 <real_or_random> ack on a using github-merge and/or related tools
19:25:12 <real_or_random> core vendors secp256k1, so the changes need to be accepted there too
19:25:30 <wumpus> #action move github-merge.py to bitcoin-maintainer-tools repo
19:25:55 <sipa> real_or_random: occasionally we open a PR to core that updates the subtree, summarizing the changes
19:25:58 <real_or_random> but tbh, if we open a large +500/-500 PR from time to time, it's too late to spot weirdnesses
19:26:32 <sipa> yeah perhaps that's a question whether people here prefer more regular updates of the subtree
19:26:50 <real_or_random> yes, indeed. I think my point is that these tend to get ACKed with the idea in mind that they're fine because they were merged in secp256k1
19:26:59 <wumpus> it's another opportunity for review, though yes, if it groups too many different things it'll likely not get more than cursory glances
19:27:27 <real_or_random> so it makes sense to have the same careful committing/merging process for secp too
19:27:30 <wumpus> also a lot of bitcoin core reviewers don't have much knowledge of the details of the cryptography and implementation
19:27:37 <wumpus> yes
19:27:40 <real_or_random> right
19:27:55 <real_or_random> sipa: this question is also related to possible releases
19:28:17 <real_or_random> AFAIK it was always planned to have releases, we may reconsider that
19:28:29 <sipa> yeah
19:28:45 <sipa> i guess not everything needs to be resolved in this meeting
19:28:50 <real_or_random> sure
19:28:50 <sipa> but it's good to have some communication
19:30:27 <wumpus> yes, it's fine, it's not like there's other proposed topics for this meeting :) and I don't think sharing a meeting with secp256k1 stuff is that bad so people are aware what is happening there
19:30:48 <sipa> high priority for review?
19:30:57 <wumpus> oh yes, we could do that
19:31:04 <wumpus> #topic High priority for review
19:31:11 <BlueMatt> an I add #16421 to the list?
19:31:14 <gribble> https://github.com/bitcoin/bitcoin/issues/16421 | Conservatively accept RBF bumps bumping one tx at the package limits by TheBlueMatt · Pull Request #16421 · bitcoin/bitcoin · GitHub
19:31:49 <wumpus> sure we can always add more, I'm most interested in whether some things are getting ready for merge though :)
19:32:39 <aj> BlueMatt: fanquake did that already i thought?
19:32:58 <jeremyrubin> correct
19:33:02 <BlueMatt> oh, maybe
19:33:14 <BlueMatt> I just want to get it in for .19, and its gotten very little review
19:33:19 <BlueMatt> despite being an incredibly simple pr
19:33:21 <instagibbs> BlueMatt, will review
19:33:37 <MarcoFalke> I think we got three high-prio things merged this week
19:33:42 <MarcoFalke> maybe even more
19:33:56 <wumpus> 8 things on the list is a lot though
19:34:07 <wumpus> oh one is merged, good
19:34:13 <aj> oh fanquake added 16400
19:35:07 <MarcoFalke> #16400 should get removed
19:35:10 <gribble> https://github.com/bitcoin/bitcoin/issues/16400 | [refactor] Rewrite AcceptToMemoryPoolWorker() using smaller parts by sdaftuar · Pull Request #16400 · bitcoin/bitcoin · GitHub
19:35:17 <wumpus> so yes, the soft translation string freeze for 0.19 is already in two weeks, the feature freeze in a month
19:35:33 <MarcoFalke> It needs rebase and I think #15759 was in first
19:35:36 <gribble> https://github.com/bitcoin/bitcoin/issues/15759 | [p2p] Add 2 outbound blocks-only connections by sdaftuar · Pull Request #15759 · bitcoin/bitcoin · GitHub
19:36:22 <wumpus> ok
19:37:14 <wumpus> 16400 removed from now, let's re-add it after 15759 merged
19:38:25 <wumpus> anything else to discuss?
19:39:57 <wumpus> #endmeeting