[11:41] *** This channel was created on 15 Apr 2019 17:49:27.
[12:04] <fanquake> Will this channel be logged anywhere/the discussions recapped?
[13:00] <jnewbery> I'm not logging it but this a public channel so you're welcome to set it up!
[14:07] <Emcy> nice idea for a channel
[15:43] <ironbutt> hi, i'm new in IRC and actually not sure if it works or not
[15:45] <booyah> ATH when?
[15:46] <booyah> wait, wrong channel. PR rev when?   :)
[15:46] <booyah> 3 hours, nice
[18:29] <emzy> Wow full here.
[18:32] <bilthon> hi there, I'm a bit early I know
[18:32] <bilthon> I just wanted to take some time to switch to that PR's branch
[18:33] <bilthon> it seems it has been merged already
[18:34] <emzy> I just build the master. Not shure if that is right.
[18:35] <bilthon> I also have a previously cloned version of the repo at master. But I think to target the specific PR we should clone from here: https://github.com/instagibbs/bitcoin/tree/bumpall
[18:37] <bilthon> well in this case since  #15557 appears to have already been merged the master would already contain it
[18:38] <moneyball> bilthon: it was recently merged but still worthwhile reviewing. future PR reviews will probably include PRs that are still open. either way a valuable learning experience and would be valuable if we find a bug :)
[18:38] <bilthon> sure, of course
[18:42] <bilthon> the PR is a github concept, not git right?
[18:42] <bilthon> I mean, there's no command that would allow me to "switch" to the unmerged PR branch since it is in another repo
[18:43] <bilthon> I'm cloning the whole repo from instagibbs and it takes its sweet time
[18:43] <jnewbery> You can check out the pull request branch directly from github.com/bitcoin/bitcoin
[18:43] <jnewbery> git fetch upstream pull/15557/head:pr15557
[18:43] <bilthon> or maybe can I just apply a patch to master and review it there?
[18:43] <jnewbery> git checkout pr15557
[18:43] <jnewbery> (assuming github.com/bitcoin/bitcoin is your upstream remote)
[18:44] <jnewbery> details on checking out pull requests from github: https://help.github.com/en/articles/checking-out-pull-requests-locally
[18:45] <bilthon> great! that's what I wanted
[18:45] <bilthon> learning something already
[18:46] <bilthon> git fetch origin pull/15557/head:pr15557
[18:46] <bilthon> is what worked for me
[18:47] <MarcoFalke> If you have a large hard drive and fast internet connection, you may also download all pull requests in one go: https://github.com/bitcoin/bitcoin/blob/master/doc/productivity.md#reference-prs-easily-with-refspecs
[18:47] <MarcoFalke> jnewbery: Could link to https://github.com/bitcoin/bitcoin/blob/master/doc/productivity.md in the gist?
[18:48] <jnewbery> bilthon: that's because your 'origin' remote is github.com/bitcoin/bitcoin. My setup is to have my 'origin' remote pointing to jnewbery/bitcoin and my 'upstream' remote pointing to bitcoin/bitcoin
[18:48] <jnewbery> MarcoFalke: good idea. Thanks
[18:49] <jnewbery> done
[18:51] <jnewbery> we'll get started in 10 minutes
[18:52] <ecurrencyhodler> :+1:
[19:01] <jnewbery> Hi folks!
[19:01] <harding> Hi!
[19:01] <dmkathayat> Hello!
[19:01] <schmidty> hola
[19:01] <amiti> hi!
[19:01] <bilthon> hi there
[19:01] <jnewbery> We usually start Bitcoin Core IRC meetings with a 'hi' so it's clear who's at keyboard. Feel free to say hi here!
[19:01] <kcalvinalvin> Hi
[19:01] <peevsie> hi!
[19:02] <emzy> Hi
[19:02] <ajonas> Hi!
[19:02] <RubenSomsen> hi :)
[19:02] <mryandao> hi
[19:02] <merehap> Hey!
[19:02] <MrPaz> Hi!
[19:02] <aj> *yawn*
[19:02] <TomA> Hi
[19:02] <bitcoinerrrr> hey ya'll
[19:02] <b10c> Hi!
[19:02] <sebastianvstaa> hi
[19:02] <jnewbery> I expect we'll take a couple of weeks to figure out the format. We can iterate as we figure out what works best
[19:02] *** bitcoinerrrr is now known as juscamarena.
[19:02] <moneyball> hi
[19:02] <jnewbery> aj! Glad you could make it!
[19:02] *** juscamarena is now known as juscamarenaaa.
[19:02] <fanquake> heh aj
[19:03] <jnewbery> and fanquake!
[19:03] <aj> fanquake: woah
[19:03] <udiWertheimer> Hi
[19:03] <rafeeki> hi all
[19:03] <jnewbery> welcome to our antipodean insomniacs
[19:03] <manjaroi3> hi
[19:04] <ariard> hi!
[19:04] <jnewbery> I'll start by giving a very brief summary of the PR and then throw open to questions
[19:04] *** manjaroi3 is now known as justinmoon.
[19:05] <jnewbery> bumpfee is a command in the Bitcoin Core wallet to create an RBF transaction. It takes an unconfirmed transactions and then 'bumps' the fee on it by reducing the value of the change output
[19:05] <jnewbery> previously that command would fail if there wasn't a change output, or the change output was too small
[19:05] <jnewbery> this PR allows the fee to be bumped on transactions without change or with small change by adding a new input to the bumped transaction
[19:06] <jnewbery> (I choose it a couple of weeks ago before it was merged, but I think it's still useful to review even though it's now merged)
[19:06] <jnewbery> I think that's enough summary from me. Did anyone have any questions about the PR?
[19:06] <jnewbery> don't be shy :)
[19:06] <moneyball> thanks for that description. it more clearly explains it than what is in the PR summary.
[19:07] <bilthon> oh this is a very nice feature, I had a tx with no change stuck in the mempool for days once because I could not bump its fee
[19:07] <ecurrencyhodler> hi
[19:07] <jnewbery> yeah, instagibbs description is accurate, but assumes some knowledge of what bumpfee is already doing
[19:08] <udiWertheimer> The description mentions negative value inputs. What are those?
[19:08] <bilthon> yeah, this brief summary definitely cleared things up for me
[19:08] <emzy> Good summary!
[19:09] <b10c> What is knapsack coin selection? quick tl;dr?
[19:09] <jnewbery> udiWertheimer: good question! When selecting coins to include in a transaction, each coin has a value, but there's also the cost associated with spending that coin, because it adds to the weight of the transaction
[19:09] <jnewbery> I think that instagibbs means adding coins where the cost of spending the coin is greater than the value of the coin
[19:10] <harding> b10c: are you familar with: https://en.wikipedia.org/wiki/Knapsack_problem ?
[19:10] <moneyball> b10c: section 3.4.4 http://murch.one/wp-content/uploads/2016/11/erhardt2016coinselection.pdf
[19:10] <udiWertheimer> jnewbery: aaah gotcha. thanks!
[19:10] <jnewbery> knapsack coin selection is the old method for doing coin selection in the wallet (pre branch-and-bound)
[19:10] <ariard> Not on this PR specifically, but would you set out what process are you following when you review any PR on core, are you reading functions comment first? checking code flow change? etc
[19:11] <afig_> SHP0119410
[19:11] <merehap> Is there a privacy trade-off in adding the initially unselected output to bump the fee rate (i.e. mixing different outputs)? If there is, would that kind of topic come up during the PR review?
[19:11] <jnewbery> ariard: I'll read the PR description, then do a quick skim through the PR branch commit-wise to get an idea of the overall shape of the changes, and then go through each commit in more detail
[19:12] <b10c> thanks harding, moneyball
[19:12] <harding> merehap: I don't understand the first part of your question, but privacy concerns should certainly come up on PR reviews.
[19:12] <jnewbery> merehap: definitely privacy concerns are in scope for PR reviews!
[19:13] <jnewbery> I think the question is whether adding a new coin allows a spy to correlate togther the inputs
[19:14] <merehap> When bumping the fee rate and including a new output, you are linking previously unlinked outputs (by my understanding). Probably not important to go into depth here though.
[19:14] <ariard> oky thanks
[19:14] <merehap> Yeah
[19:14] <rafeeki> is it typical for a PR like this to come with a pre-written test like wallet_bumpfee.py?
[19:14] <udiWertheimer> merehap: unfortunately there’s usually some privacy-related trade off with bumping fees. Even if you don’t add an input, you will expose which of the outputs is your change output (the one that changes), which otherwise would be harder to figure out
[19:14] <bilthon> what's up with the "concept ACK" replies down there
[19:15] <mryandao> isnt that a similar risk to spending when you consolidate utxos without fee-bumping?
[19:15] <jnewbery> It's a good consideration. Whenever you spend multiple inputs in the same transaction, you're revealing some information about the ownership of those coins (module coinjoin, P2EP, etc). That's true for normal transactions and bumped transactions
[19:15] <merehap> Yeah, just curious how those trade-offs are exposed to the user.
[19:15] <harding> merehap: ah.  That's an interesting question.  I think it didn't come up in the review because linknig together inputs in inherent in sending transactions at all, whether the user is sending a new transaction or bumping the fee of an existing transaction.
[19:16] <merehap> Cool
[19:16] <jnewbery> rafeeki: our test coverage in the wallet with functional tests is pretty good. I'd expect all big new features to include tests
[19:17] <karimofthecrop> @jnewbery - can you repost your summary for those of us that weren't quite on time?
[19:17] <jnewbery> bumpfee was added a couple of years ago and had pretty good test coverage, so it was pretty straightforward for instagibbs to add new tests
[19:17] <fanquake> bilthon: Checkout https://github.com/bitcoin/bitcoin/blob/master/CONTRIBUTING.md#peer-review. It's basically a way of saying you agree with the changes, but haven't done much, if any review yet.
[19:17] <jnewbery> thanks fanquake
[19:17] <mryandao> the only bit i'm curious about is where the dust utxo gets destroyed and contributes to fee instead.
[19:17] <MrPaz> so if I understand correctly, before you couldn't increase fee because there weren't enough sats in input and there was simply no way to add a new input.  now there is a way to add new input to bump fee, and it will look for uneconomic inputs to use in bumping fee?
[19:18] <mryandao> and dust threshold may increase/decrease in the future?
[19:18] <ecurrencyhodler> karimofthecrop: bumpfee is a command in the Bitcoin Core wallet to create an RBF transaction. It takes an unconfirmed transactions and then 'bumps' the fee on it by reducing the value of the change output  previously that command would fail if there wasn't a change output, or the change output was too small  this PR allows the fee to be bumped on transactions without change or with small change by adding a n
[19:18] <ecurrencyhodler> Copy pasted from jnewbery
[19:18] <karimofthecrop> th
[19:18] <karimofthecrop> thx
[19:19] <jnewbery> ...by adding a new input to the bumped transaction
[19:20] <jnewbery> mryandao: that bit is here: https://github.com/bitcoin/bitcoin/blob/master/src/wallet/feebumper.cpp#L184
[19:20] <jnewbery> yes, I suppose the dust threshold could change in future. It's a policy rule, not consensus
[19:21] <mryandao> so yes, the idea here is my maybe-future-spendable dust gets chucked into fee and I overpaid.
[19:21] <jnewbery> MrPaz: it will look for any inputs to add to the transactions. It just happens that it might pick uneconomical inputs as part of that knapsack search
[19:21] <mryandao> but i guess, the dust is low enough to be immaterial
[19:22] <harding> mryandao: I don't think that's something this PR changes, as it's Bitcoin Core's existing wallet policy to not send outputs that may cost more to spend than they're worth.
[19:22] <jnewbery> mryandao: the idea is to not reduce that change output to below dust so that the replacement transaction is able to be relayed
[19:22] <harding> (Or even somewhat above that limit, as eliminating change outputs brings a privacy benefit.)
[19:23] <mryandao> mm ok - relay policy gotcha.
[19:23] <-- TomA (4576f2e9@gateway/web/freenode/ip.69.118.242.233) has left this server (Quit: Page closed).
[19:23] <dmkathayat> jnewbery: What does CoinControl's m_min_depth do?
[19:24] <rafeeki> jnewbery: thanks! I liked the idea of starting to contribute just by running/writing test cases. It surprised me that this one was so formulaic. I guess in future weeks we will see other examples that may need more testing?
[19:24] <jnewbery> take a look at the definition of CoinControl here: https://github.com/bitcoin/bitcoin/blob/master/src/wallet/coincontrol.h#L15
[19:24] <harding> rafeeki: I think this PR probably could've used more tests, and contributions to testing are welcome independently from the PRs that implement the features.
[19:25] <jnewbery> the idea of CoinControl is that it can be used to control how a transaction is constructed by the wallet
[19:25] <jnewbery> I believe it's grown over the years, but I guess it was originally just for selecting which coins to include as inputs in the transaction
[19:26] <kcalvinalvin> I don't think I'm quite understanding the policy rules. if (dust output > 0); return false; is this correct?
[19:26] <jnewbery> m_min_depth just says "don't select coins that have fewer than this many confirmations as inputs"
[19:26] <aj> harding: while you're reviewing adding tests yourself help you understand the behaviour, and you can send them to the author who can add them to the PR too. super helpful in my opinion
[19:27] <harding> aj: agreed!
[19:27] <jnewbery> refeeki/harding: manual testing of new features is always welcome. And like aj says, contributing automated tests to the PR author is a really helpful way to start contributing
[19:28] <mryandao> we can only bumpfee once?
[19:28] <jnewbery> eg one of my early contributions here: https://github.com/bitcoin/bitcoin/pull/9484#issuecomment-272547796 was adding tests for a new feature which didn't have test coverage
[19:28] <harding> In case it's helpful to anyone, I took a quick look at the PR earlier and made notes about what I'd test for it: https://gist.github.com/harding/168f82e7986a1befb0e785957fb600dd
[19:29] <jnewbery> I really appreciate it when someone reviews my PRs and provides additional tests
[19:29] <mryandao> src/wallet/feebumper.cpp#299
[19:29] <merehap> harding: Yeah, very helpful.
[19:29] <jnewbery> harding: awesome. Thanks!
[19:30] <jnewbery> A comment like that in the PR is really helpful in review: "here's what I tested an my methodology"
[19:30] <jnewbery> mryandoa: no, it's possible to bump multiple times
[19:30] <jnewbery> BIP 125 describes bitcoin core's mempool policy for allowing txs to be replaced : https://github.com/bitcoin/bips/blob/master/bip-0125.mediawiki
[19:31] <jnewbery> each subsequent bump must fulfil those conditions, eg each must have a feerate higher than the previous
[19:32] <dmkathayat> Not specific to this PR, but do you review PRs directly on github or on your terminal? I'm finding it tricky to just read through the line changes on github.
[19:32] <mryandao> jnewbery: thanks for that.
[19:32] <jnewbery> I never review on github, partly because the diff view is not very helpful, and partly to avoid trusting a third party
[19:32] <rafeeki> harding/jnewbery/aj: thanks so much! great feedback and examples
[19:32] <moneyball> bilthon: concept ACK just means that the reviewer acknowledges and agrees with the concept of the change, but is not (yet) confirming they've looked at the code or tested it. this can be a valuable signal to a PR author to let them know that the PR has merit and is headed in the right direction.
[19:33] <jnewbery> I check out the branch locally and then run a difftool on each commit in turn, and then ACK the commit hash of the HEAD commit
[19:34] <jnewbery> ymmv, but the current difftools I use are meld on linux and opendiff on mac
[19:34] <aj> i find skimming on github helpful, but yeah, always actually review locally... i find "gitk" useful for getting an overview of changes
[19:35] <mryandao> my tagger is broken, even browsing the python test scripts, the tags point back to the cpp source
[19:35] <karimofthecrop> jnewbery: what do you mean "ACK the commit hash of the HEAD commit" - where do you ACK? On github?
[19:35] <ariard> jnewbery: which are the good bitcoin dev tooling repos? Seems like everyone I've its own? Are they listed somewhere to dig in?
[19:35] <dmkathayat> Great, thanks!
[19:35] <ariard> s/I've/have/
[19:35] <jnewbery> karimofthecrop: here for example: https://github.com/bitcoin/bitcoin/pull/15557#issuecomment-482139144
[19:36] <harding> ariard: https://github.com/bitcoin/bitcoin/blob/master/doc/productivity.md has some tips on tools and tricks
[19:36] <jnewbery> this means: I've reviewed the branch that ends in commit 184f878, and I think it's ready for merge
[19:36] <karimofthecrop> I see, I hadn't noticed hashes in previous ACKs. Is this considerd best practice?
[19:36] <jnewbery> that commit hash is from my local checkout of the branch, so unless my local tools are compromised, I know I'm ACKing the exact changes
[19:36] <instagibbs> It's useful when a force push happens and links to old commits are lost on github
[19:36] <jnewbery> If I took that commit hash from github, they could be lying to me
[19:37] <instagibbs> (that too)
[19:37] <ariard> harding: thanks this doc is great, was more thinking to pre-push git script to be sure I don't forget any tests before to PR
[19:37] <fanquake> ariard I have some tools, info & random stuff in https://github.com/fanquake/core-review. Has guides on how to gitian build, review certain types of PRs etc.
[19:37] <instagibbs> although unless you gpg sign the ACK, they could just modify what you're saying :)
[19:38] <fanquake> I still need to improve the docs, and push up some more stuff I have sitting locally.
[19:38] <ariard> fanquake: thanks bookmarked, maybe could be linked at the end of productivity.md?
[19:38] <jnewbery> instagibbs: indeed. If you want to fully remove trust, you can go the full MarcoFalke and sign/opentimestamp all of your review comments :)
[19:38] <b10c> fanquake: thanks!
[19:38] <karimofthecrop> does anyone devel in a docker container instead of a vagrant box?
[19:39] <fanquake> ariard: I don't think that'd be the right place for personal type repositories.
[19:39] <karimofthecrop> I have seen some docker containers, wondering if there is a preferred/blessed one.
[19:39] <fanquake> There is also https://github.com/bitcoin-core/bitcoin-maintainer-tools, if your looking for something more official.
[19:40] <ariard> okay got it, it just to be aware of good practices to avoid having to rewrite same scripts it has already been done
[19:40] <ariard> but yes we have all different setups
[19:40] <instagibbs> a bit like herding cats, everyone has their own setup
[19:41] <ariard> and workflow
[19:41] <jnewbery> yeah, I think there probably is no royal road to your dev setup. You build it up over the years
[19:41] <karimofthecrop> instagibbs: has there ever been problems due to inconsistent environments?
[19:41] <amiti> would love to hear about some of your personal setups
[19:42] <instagibbs> karimofthecrop, rarely? I mean, I say this as someone running a very common OS in developer circles
[19:42] <fanquake> karimofthecrop: infrequently bugs have made it into the codebase due to lack of testing on certain OSes.
[19:42] <karimofthecrop> is there a need for continuous integration to avoid that?
[19:42] <emzy> Some OS that is missing testing?
[19:42] <jnewbery> amit: vagrant, vim+various Tim Pope plugins, git :)
[19:43] <jnewbery> *amiti
[19:43] <mryandao> all tests passed on my end.
[19:44] <ariard> jnewbery's great piece on tooling https://bitcointechtalk.com/contributing-to-bitcoin-core-a-personal-account-35f3a594340b !
[19:44] <jnewbery> haha thanks ariard. That's more about generally contributing than specific tools
[19:45] <fanquake> emzy: One example was https://github.com/bitcoin/bitcoin/pull/9598, which broke compilation on FreeBSD. Later fixed in https://github.com/bitcoin/bitcoin/pull/13503.
[19:45] <amiti> hm yeah, have read that piece, but am more interested in build environments
[19:45] <ariard> well at least read the sharpening the tool part sometimes ago, was helpful thanks
[19:46] <fanquake> amiti: I test on macOS, then use a mixture of Docker & vagrant to test on other OS's. Generally build related stuff.
[19:46] <jnewbery> we now have Travis and appveyor CIs for testing in linux/windows, although appveyor is still a bit flakey I think
[19:46] <ariard> yes build is quicly a bottleneck when you want to parallelize your workflow
[19:46] <afig_> wish i could be a little more involved in the chat but i am currently at work. This is helpful!
[19:47] <fanquake> We've got at least one BSD CI now, but it's not integrated into the repo.
[19:47] <karimofthecrop> fanquake: it would seem that a) this isn't a big problem and b) not many nodes on freebsd :P
[19:47] <jnewbery> afig_: yeah, it's impossible to have a time that's convenient for everyone. Thanks for logging in anyway
[19:47] <karimofthecrop> what afig_ said. very useful!
[19:47] <kcalvinalvin> What distros are must checks for a PR
[19:48] <fanquake> kcalvinalvin: rough list for build related changes https://github.com/fanquake/core-review/blob/master/operating-systems.md
[19:49] <instagibbs> kcalvinalvin, in general most changes won't require careful checks of that kind. Unless it involves low-level networking, GUI, ???
[19:50] <jnewbery> kcalvinalvin: it's a good question. In this case, the changes are all at a higher application-level, so very unlikely to have portability issues
[19:50] <jnewbery> ok, we'll wrap up in 10 minutes. If you have any questions that you've been holding back on, now's the time!
[19:50] <fanquake> Also depends on what the expectations are in regards to building with provided libraries or depends. i.e qt is somewhat broken on debian atm: https://github.com/bitcoin/bitcoin/issues/15453
[19:51] <karimofthecrop> jnewbery: how would one go about picking a PR that could use some testing love, as you and harding suggested earlier?
[19:51] <karimofthecrop> there are 294 currently open!
[19:52] <jnewbery> I'm not sure if there's a quick way to identify which PRs could use additional testing without looking at them. In general, I'd recommend that you pick one subsystem that you're interested in (eg wallet, testing framework, rpc, net), and try to survey all the open PRs in that area, then identify which ones you think need additional testing/review
[19:53] <fanquake> jnewbery: maybe worth mentioning https://github.com/bitcoin/bitcoin/projects/8 ?
[19:54] <mryandao> test/functional/wallet_bumpfee.py#313 -- are we unlocking the wallet again after the rpc error was thrown when trying to bump fee?
[19:54] <emzy> Is this helping?  https://bitcoinacks.com/
[19:54] <harding> karimofthecrop: there's also https://gist.github.com/jnewbery/6e2797a6f484de59aefc849a6b184008 , which has the PRs planned to be discussed here in the next couple weeks.  I don't know if any of them need more tests written, but it'd be worth checking.
[19:54] <karimofthecrop> is it fair to suspect that "needs rebase" tag inidcates a) has enough love and/or b) is kinds stuck?
[19:54] <karimofthecrop> ^kinds^kinda^
[19:54] <-- amiti (6bd29f36@gateway/web/freenode/ip.107.210.159.54) has left this server (Ping timeout: 256 seconds).
[19:54] <jnewbery> or feel free to ask in #bitcoin-core-dev. An "I'm interested in helping test wallet/net/etc PRs and I'm looking for PRs to help on" would definitely be well received
[19:55] <jnewbery> fanquake: yes, those are high-priority for review PRs. You should expect to see more action on those than the average PR. Definitely worth knowing what's on there and what other people are looking at
[19:56] <jnewbery> karimofthecrop: if a PR has needed rebase for a while (say more than a week or so), then I interpret it as the author not actively working on it, so I tend to avoid review until it's more active
[19:56] <harding> karimofthecrop: for how much love a PR has, you're probably looking for how many ACKs it has from well-know contributors.
[19:57] <jnewbery> but definitely feel free to prod authors. You can leave a comment saying "I
[19:57] <jnewbery> 'd like to review this, but I want to make sure that it's still being actively maintained"
[19:57] <jnewbery> I think that's fine. I wouldn't mind recieving that comment on my PRs
[19:57] <jonatack> hi! just learned about this excellent initiative. is there a link to a log of this chat?
[19:57] <karimofthecrop> prod via public comment? or dm?
[19:58] <jnewbery> either is fine I think
[19:58] <harding> jonatack: AFAIK, we don't have logging setup, but I can put up something in a couple minutes when the chat is over.
[19:58] <jnewbery> other contributors: feel free to chime in if you don't think that's a good idea
[19:59] <jonatack> thank you
[19:59] <jnewbery> harding: that'd be awesome (as long as other people think it'd be useful)
[19:59] <kcalvinalvin> thanks for this, it was really helpful. Will be back next week
[19:59] <fanquake> jnewbery: I agree either is fine. On GH just has the advantage of other interested parties also seeing that someone has reached out.
[20:00] <jnewbery> ok, let's wrap it up here. Upcoming PRs to review are here: https://gist.github.com/jnewbery/6e2797a6f484de59aefc849a6b184008
[20:00] <jnewbery> Thanks everyone!
[20:00] <mryandao> the assumeutxo one looks like a big one
[20:00] <jamesc> Thanks jnewbery!
[20:00] <b10c> jnewbery: thank you!
[20:00] <MrPaz> thank you!
[20:00] <harding> jnewbery: thank you!
[20:00] <merehap> Thanks! This was very helpful. Love the idea and thanks for taking the initiative to run this!
[20:00] <sebastianvstaa> thanks jnewberry! that was very helpful. will be back next week.
[20:00] <peevsie> This was great, thanks!
[20:00] <emzy> Thanks jnewbery
[20:00] <ecurrencyhodler> Thank you!!
[20:01] <Lightlike> Thank you, very helpful!
[20:01] <karimofthecrop> +1 all the thanks :D
[20:01] <-- mryandao (~mryandao@gateway/tor-sasl/mryandao) has left this channel.
[20:01] <-- jamesc (~jamesc@192.38.137.203) has left this server (Quit: WeeChat 2.0.1).
[20:01] <-- kcalvinalvin (6e0e9879@gateway/web/freenode/ip.110.14.152.121) has left this server (Quit: Page closed).
[20:01] <bilthon> thanks jnewbery, got sidetracked there with some of the links you guys sent, definitely will be back here next week
[20:01] <rafeeki> thanks all! Looking forward to next week
[20:01] <-- karimofthecrop (~user@rrcs-69-75-253-202.west.biz.rr.com) has left this channel ("ERC (IRC client for Emacs 25.3.1)").
[20:01] <RubenSomsen> Thanks John :)
[20:01] <jnewbery> Feedback is most definitely welcome. Also let me know if you have suggestions for PRs to cover. The aim is for manageable sized PRs (ie 100-150 LOC change seems about right), not too much contextual knowledge required, and trying to cover all the different components
[20:02] <jnewbery> Feel free to leave feedback in this IRC channel. I'll be monitoring through the week
[20:02] <afig_> Thanks!
[20:02] <iiiiiiiiii> would it be helpful if calendaring/events were created for the PR meeting?
[20:03] <-- bilthon (be2b9b04@gateway/web/freenode/ip.190.43.155.4) has left this channel.
[20:03] <-- Lightlike (6d2881e5@gateway/web/freenode/ip.109.40.129.229) has left this server (Quit: Page closed).
[20:05] <-- afig_ (642bef32@gateway/web/freenode/ip.100.43.239.50) has left this server (Quit: Page closed).
[20:05] <-- iiiiiiiiii (~iiiiiiiii@185.212.170.140) has left this server (Quit: iiiiiiiiii).
[20:05] <jnewbery> iiiiiiiiii: I'm not sure I can help you with that. It's 17:00 UTC Wednesday every week
[20:06] <jnewbery> thanks especially to harding, aj, fanquake, instagibbs and MarcoFalke. Really useful to have your input
[20:07] <harding> Here's a log: https://gist.githubusercontent.com/harding/ea914ee7129e8b33dd429f3886d01c8f/raw/f74c65235049242dd5b482be99b065cbfeca59bf/bitcoin-core-pr-reviews-2019-05-01.txt
[20:07] <RubenSomsen> jnewbery: here's a link with the entire session: https://www.irccloud.com/pastebin/u74tZsg9/Bitcoin%20Core%20PR%20review%20%231
[20:07] <RubenSomsen> harding: ah, you beat me to it :)
[20:08] <merehap> harding: Thanks! I'll now be able to refer back to this session long after I've lost the 20+ browser tabs that I opened from it. :-)
[20:08] <merehap> RubenSomsen: Also thanks :-)
[20:08] <jonatack> harding, RubenSomsen: thank you!
[20:09] <davterra> thank you jnewbery
[20:09] <-- sebastianvstaa (~sebastian@ip-37-201-5-128.hsi13.unitymediagroup.de) has left this server (Ping timeout: 245 seconds).
[20:12] <-- ecurrencyhodler (2f9a6dce@gateway/web/freenode/ip.47.154.109.206) has left this server (Quit: Page closed).
[20:29] <-- merehap (~sean@199.229.250.134) has left this server (Quit: Ex-Chat).
[20:36] <-- davterra (~none@94.100.23.163) has left this server (Quit: Leaving).
[20:56] <-- MrPaz (~MrPaz@c-71-57-73-68.hsd1.il.comcast.net) has left this server (Ping timeout: 244 seconds).
[21:24] <-- peevsie (peevsie@gateway/vpn/privateinternetaccess/peevsie) has left this channel ("Konversation terminated!").
[21:50] <-- juscamarenaaa (2f94aac8@gateway/web/cgi-irc/kiwiirc.com/ip.47.148.170.200) has left this server (Remote host closed the connection).
[22:26] <realchain> Oh no, did I miss it?
[22:29] <harding> realchain: only this week's meeting; we'll be doing it again next week on Wednesday at 17:00 UTC.  Here's a log of this week's meeting if you want to read it: https://gist.githubusercontent.com/harding/ea914ee7129e8b33dd429f3886d01c8f/raw/f74c65235049242dd5b482be99b065cbfeca59bf/bitcoin-core-pr-reviews-2019-05-01.txt
[22:30] <realchain> Thank you. Next week then
[22:36] <-- realchain (29502ed4@gateway/web/freenode/ip.41.80.46.212) has left this server (Ping timeout: 256 seconds).
[23:02] <-- justinmoon (~manjaro-i@cpe-70-113-80-71.austin.res.rr.com) has left this server (Remote host closed the connection).
[23:06] <-- jnewbery (~john@static-100-38-11-146.nycmny.fios.verizon.net) has left this server (Quit: leaving).
[23:21] <-- b10c (~b10c@2001:16b8:2e53:9100:9c62:2470:6384:206b) has left this server (Read error: Connection reset by peer).
[23:57] <-- ajonas (~ajonas@static-100-38-11-146.nycmny.fios.verizon.net) has left this server (Ping timeout: 250 seconds).
[00:07] <dmar198> did anyone take a log of the discussion from earlier today?
[00:12] <emzy> Here's a log of this week's meeting if you want to read it: https://gist.githubusercontent.com/harding/ea914ee7129e8b33dd429f3886d01c8f/raw/f74c65235049242dd5b482be99b065cbfeca59bf/bitcoin-core-pr-reviews-2019-05-01.txt
[00:16] <dmar198> thank you!
[00:34] <dmar198> exit
[00:34] <-- dmar198 (491226d9@gateway/web/freenode/ip.73.18.38.217) has left this server.
[10:27] <-- jonatack (52661ba3@gateway/web/freenode/ip.82.102.27.163) has left this server (Quit: Page closed).
[12:15] <Zenton> hello, is this channel logged anywhere?
[12:31] <fanquake> Zenton: no logs, but there is a recap of yesterdays chat up here: https://gist.githubusercontent.com/harding/ea914ee7129e8b33dd429f3886d01c8f/raw/f74c65235049242dd5b482be99b065cbfeca59bf/bitcoin-core-pr-reviews-2019-05-01.txt
[12:32] <Zenton> thank you