19:00:05 #startmeeting 19:00:05 Meeting started Thu Sep 13 19:00:05 2018 UTC. The chair is wumpus. Information about MeetBot at http://wiki.debian.org/MeetBot. 19:00:05 Useful Commands: #action #agreed #help #info #idea #link #topic. 19:00:06 Would have to remove the #include of libssl as well? 19:00:13 oh meeting 19:00:16 MarcoFalke: yep 19:00:17 hi 19:00:24 hi 19:00:36 I wonder if it is possible to build openssl with just libcrypto and not libssl 19:01:17 hi 19:01:50 any proposed topics? 19:01:54 hi 19:01:59 Hi 19:02:04 Have we had issues reported for rc3 of 0.17.0? 19:02:22 MarcoFalke: probably not: https://github.com/openssl/openssl/issues/4597 19:02:58 MarcoFalke: I don't think so 19:02:59 hi 19:03:07 MarcoFalke: there was that thing sipa pointed out 19:03:09 with psbt 19:03:19 #14196 19:03:20 https://github.com/bitcoin/bitcoin/issues/14196 | [0.17][psbt] always drop the unnecessary utxo and convert non-witness utxo to witness when necessary by achow101 · Pull Request #14196 · bitcoin/bitcoin · GitHubAsset 1Asset 1 19:03:54 I'm not sure if it is necessarily a bug, it is annoying though when encountered 19:04:11 regarding missing pieces for multi wallets, hope to get #13100 and #13339 done shortly 19:04:14 https://github.com/bitcoin/bitcoin/issues/13100 | gui: Add dynamic wallets support by promag · Pull Request #13100 · bitcoin/bitcoin · GitHub 19:04:16 https://github.com/bitcoin/bitcoin/issues/13339 | wallet: Replace %w by wallet name in -walletnotify script by promag · Pull Request #13339 · bitcoin/bitcoin · GitHub 19:04:34 Ok, we should put that up as high priority and then target rc4 end of next week? 19:05:01 yes, good idea 19:05:08 i encountered this issue while actually trying to use psbt btw :) 19:05:23 Also I'd like to see the release notes amended with the list of merged changes. wumpus mind doing that or sharing the script :) ? 19:05:36 MarcoFalke: huh didn't I add those? 19:05:50 last week was like a blur 19:06:03 still too busy this week, but if someone could add scantxoutset to the release notes? 19:06:49 yes I actually added the PRs and authors: https://github.com/bitcoin-core/bitcoin-devwiki/wiki/0.17.0-Release-notes 19:06:54 wumpus: Thx. I've misssed yesterdays commit 19:08:22 Anyone up for writing a short part about scantxoutset for the 0.17 release notes? 19:08:27 as for sharing the script, if you don't mind it's a mess, will push it into devtools soon 19:09:25 I can give a try to scantxoutset release notes 19:09:46 promag: thanks! 19:10:09 some quick proposed topics: refactor/linter PRs , wallet maintainer , archiving meeting notes 19:10:37 promag: thanks! 19:11:10 added 14197 to high prio 19:11:32 #14197 19:11:34 https://github.com/bitcoin/bitcoin/issues/14197 | [psbt] Convert non-witness UTXOs to witness if witness sig created by achow101 · Pull Request #14197 · bitcoin/bitcoin · GitHub 19:11:40 #topic refactor/linter PRs 19:11:56 stop it stop it stop it stop it stop it stop it stop it stop it 19:11:58 thx :p 19:12:07 I think a lot of people get the sense that there are a lot of refactor/linter PRs these days 19:12:50 yes, it's too often 19:12:53 I'd hate to discourage any contributions, but I think it would be a better use of reviewer time and people would enjoy working on the project more if more PRs were focused on features/bugfixes :) 19:12:55 wumpus: unfortunately practicalswift isn't here to hear that 19:13:05 Lol 19:13:15 we can write a lint to prevent new linters with grep 19:13:58 I would describe the concern more broadly as there is a significant fraction of all PRs (maybe a majority) with basically no articulable direct or near term benefit to users... or even just exciting changes. In any project there is going to be some amount of house keeping for sure, and I'm super happy people want to work on bits of cleanup. 19:14:00 I've told him a few times that tcleanups are okay, but not too often, say once a month or so, but they just keep coming, it's oversnowing the useful PRs 19:14:01 I like linters and other techniques to produce code consistentency, but obviously it shouldn't be become an obsession. 19:14:24 it's becoming an obsession for me (in the negative sense) 19:14:31 I feel really bad about finding myself in a position of saying "NAK. Your code is probably fine, but it's not worth anyones time to review it because it doesn't improve things enough." 19:14:37 if this keeps up, I'll close them blindly 19:14:42 i don't understand why you can't just tag them and look at the tag once a month 19:14:47 Maybe someone should just combine them all in one giant lint PR and come back in a few months? 19:15:08 who doesn't he do that himself though? 19:15:17 ryanofsky: because 'when you look' doesn't change the fact that there is a review/correctness burden. 19:15:35 because some of us actually have to look at the list of allPRs and this is really discouraging 19:15:50 I don't think any more needs to be said about any individual contributor, but if we can all rate limit own own refactor PRs, I think we'd appreciate it 19:16:30 yes, please 19:16:53 ryanofsky: They show up in the list of pulls by default 19:16:58 however those monthly cleanups can be bigger and harder to merge 19:17:49 Also it's a lot easier to churn out 'safe' refactor/cleanup changes and it's also easier to review/comment on them, so it changes the balance of activity in the project in general. 19:17:58 Can we add a pull request GitHub template that asks for clear motivation of the changes? 19:18:05 the problem is that our proojct is one big bottleneck, I think if it was divided into hierarchical subsystems like Linux it'd be better, but it's not really possible to have that workflow with github 19:18:28 all proposed changes end up in one big list 19:18:43 I.e. The changes need to improve user experience or significantly improve developer experience 19:18:59 wumpus: dunno there, I mean, even if its subsystems, all of them need to be free of exploitable crashes. :) (okay maybe a few subsystems would really be isolated from any possible hostile input...) 19:19:10 e.g. https://blog.ffwll.ch/2017/08/github-why-cant-host-the-kernel.html 19:19:11 wumpus: is that true? If wallet and node were better separated, would it be possible to have a master branch and a wallet dev branch for example? 19:19:18 should we submodule the test system? 19:19:21 MarcoFalke: I also was thinking about articulate the benefit. 19:19:28 wumpus: that's the point of GitHub "projects" isn't it 19:19:47 er, directing people to articulate the benefit. 19:19:52 yeah ^ 19:19:59 ideally I don't want to have to look at every PR individually anymore, in the case of Linux there's subsystem maintainers that make their own tree of updates and it can be merged (or rejected) at one 19:20:30 I do think we do want general code tidying some too... but those shouldn't be a signficant fraction of the PR flow. 19:20:35 jnewbery: this is not a technical issue about separation in the source tree, Linux is also one big tree 19:20:54 wumpus: I'll read the danvet post 19:20:56 it's just that top-level PRs don't really scale 19:21:28 I can't manually, humanly, handle 200+ PRs, sorry 19:21:55 proposed topic: wallet maintainer 19:22:03 I have seen that practicalswift also runs a bot(?) to comment on pull request directly with feedback harvested from clang-tidy 19:22:04 and if it keeps going like this, at some point it's going to break down 19:22:18 I think these are more useful than linters 19:22:40 i plan to do more wallet work soon, to push descriptors and other things forward 19:22:43 so we need a different way of woring 19:22:59 now i have to run, sorry; will be back next week 19:23:08 later sipa 19:23:08 o/ 19:23:37 MarcoFalke: agree ^ 19:24:21 #topic wallet maintainer 19:25:04 MarcoFalke> I.e. The changes need to improve user experience or significantly improve developer experience <- yes 19:25:25 ok, will write up something today 19:25:34 sipa is gone, so let's assign him to be wallet maintainer? 19:25:46 ACK. 19:25:50 +1 19:25:51 i thought we already did that 19:25:53 I think wumpus has wanted a wallet maintainer for a while, and sipa is probably too busy to take that role. I wonder if there are any actions we can take to find someone to be wallet maintainer in, say, the next six months 19:25:53 I feel like he has already been assigned that role many times 19:26:03 best if it fixes a reported issue, or something that is clearly either a problem from a user perspective, a performance or security issue, etc 19:26:04 vote jnewbery for wallet maintainer :P 19:26:11 promag: -1 19:26:25 What is the wallet maintainer job description? 19:26:25 it's like a game of hot potato 19:26:29 jnewbery: I am not aware of any single person that really knows what is going on in the wallet 19:26:47 ryanofsky? 19:26:50 MarcoFalke: that makes everyone equally qualified 19:26:51 provoostenator: review and merge wallet changes 19:26:55 sipa is closest, mostly as a side effect of knowing everything. 19:27:00 provoostenator: (most importantly, understand them) 19:27:22 I think sipa is kinda the wallet maintainer... or am I wrong? 19:27:24 but seriuosly, I think it's more important to have a sensitivity to what they don't know rather than have an encyclopedic knowledge of everything 19:27:35 Well, some degree of not understanding can be compensated by not merging without ACK's from people who do. 19:27:45 yes, exactly jnewbery 19:27:51 and it's only 15k lines of code. How difficult can it be? 19:27:54 it's a matter of judgement I guess 19:28:00 jnewbery: tada, disqualified. :P 19:28:23 jnewbery: I think it's a bit cleaner now with accounts gone 19:28:32 less idiotic to understand 19:28:45 it's not even that bad if you dn't fully understand it now, if you're willing to learn it 19:29:01 So I believe the closest to a wallet maintainer would be the people that worked most on it in the last two releases 19:29:01 my point in raising this topic is not "let's find a wallet maintainer today", but "can we take steps now to identify someone who might be a good wallet maintainer in a few months" 19:29:04 yes, getting rid of accounts did make it less crazy 19:29:18 It seems that waiting around for someone to volunteer or step up hasn't really worked 19:29:28 having to support old stuff is just a pain. It's hard to do without having had a lot of exposure to the history as there are many poorly documented properties that the existing stuff obeys. 19:29:33 I wonder how Linus picks subsystem maintainers 19:29:52 though, I guess, people actually volunteer 19:29:55 jnewbery: I dunno, I think things are working in the sense that its becoming simpler and more people are contributing to that part actively than were in the past. 19:30:13 gmaxwell: we're still too bottlenecked on wumpus 19:30:16 Make a large wallet PR and the first person GitHub picks as a "suggested reviewer" is the new maintainer 19:30:18 jnewbery: yes 19:30:29 so we need to make a wumpus bot or delegate to maintainers 19:30:31 Github just doesn't really directly facilitate that kind of workflow. 19:30:39 ideally I could just leave for a bit and things would continue 19:30:50 honestly I think jnewbery has done a great job cleaning and maintaining and improving wallet code 19:31:00 the solution is to just upload wumpus's mind and then start 20 instances of him :p 19:31:05 like why are we actually bottlenecked on wumpus? perhaps wumpus needs to start tagging things with "I'm not going to merge this PR" 19:31:15 achow101: yes! 19:31:16 I'd be fine with jnewbery doing this as well. 19:31:37 jnewbery: in all honesty, would you not want the role 19:31:41 me too 19:31:42 instagibbs seems to know wallet pretty well 19:31:44 it's not like there is an actual technical physical bottleneck on wumpus. 19:31:59 I'm flattered, honestly, but already too busy with bitcoin optech, residency stuff, etc 19:32:31 perhaps something for discussion in tokyo 19:32:40 I think the bottleneck is not clicking the merge button (any of the 4 maintainers can do this) 19:32:52 The bottleneck is review and signing off on the merge 19:32:59 (when ready) 19:33:12 yes, which is not always an easy judgement, but still 19:33:19 So it's more like a "sudo ACK"? 19:33:37 well if we're concerned about review cycles then we need to talk about focusing resources on whats important. So perhaps more than 'foo maintainer' we need someone curating the priority list for a subsystem. 19:33:41 if you know a certain part of the code well enough you could be maintainer of it 19:33:53 like, in Linux, if you wrote a certain driver, you're pretty much maintainer of it by default 19:34:10 the high priority PRs things helps, at least as we close for a release... 19:34:26 We could assign jnewbery and ryanofsky and other contributors the right to sign off on wallet changes and then some maintainer merges the changes. 19:34:33 So have more than one wallet maintainer 19:34:37 well the maintainer of a subsystem would also curate prioriteit 19:34:47 the problems seems to be finding people, *NOT* finding things for them to do :) 19:34:49 MarcoFalke: isn't that the point of ACK's though? 19:34:54 MarcoFalke: isn't that basically just an ACK then 19:35:03 right achow101 19:35:20 Not every ACK means merge 19:35:39 wumpus: well curating priority projects for a subsystem is less risky task, probably more people willing to do it, and fewer concerns about whos doing it. 19:35:40 more like the "sudo ACK" (provoostenator) 19:35:42 well it's more subtle than that, otherwise it could jsut be a bot 19:36:08 In the future I want it to be done by a bot, but thats a differnt topic 19:36:10 you also have to have a feeling who is the right person to ACK something 19:36:21 which would be possible if someone was a maintainer of that subsystem 19:36:30 Does Github allow putting a "maintainer" badge on someone so it's more obvious for people that these maintainer ACK's are required / strongly recommended. 19:36:32 but we're circling around 19:36:42 like who would actually understand if this is broken or will cause problems down the road, vs who just looked at it and went yep no undefined behavior! 19:36:44 provoostenator: mo 19:36:46 No* 19:36:54 gmaxwell: righ 19:37:21 anyhow, if someone wants to be wallet maintainer, or maintainer of some other subsystem, let me know 19:37:30 provoostenator: maintainers.md 19:37:51 clarkmoody: yep 19:37:56 Ok, that works. 19:38:07 you can define a path there, and who is maintainer, I think github even parses it somehow 19:38:22 and what should a maintainer do? :P 19:38:25 So in terms of steps, be more active I'm looking for someone to push into the role? What else is possible 19:38:31 In* 19:38:56 https://blog.github.com/2017-07-06-introducing-code-owners/ 19:38:58 I think we should all act as though we were the maintainers of things more. 19:39:04 meshcollider: yes, I think so 19:39:20 promag: just be very active in maintaining a piece of code, like, review all PRs that change it, judge when a change is good, etc 19:39:41 not only does this potentially reduce work for others, but it helps identify people who are organically doing the job anyways. Which is, for the most part, what other projects do. 19:39:56 I think the issue wumpus struggles with is in part because no one is doing the job already. 19:40:02 :) 19:40:30 If someone were, it would be both less of an issue, and an easier thing to decide. 19:41:10 I mean I could pull a Guido van Rossum and just stop merging things and let you figure it out for yourself, but I'd prefer to have a saner path forward 19:41:45 So we can just mark a bunch of people as Code Owners (as well maintainers.md) for the wallet and require review from at least one of them, as a step in the right direction? 19:41:49 but it's not given that I will be doing this forever 19:41:49 anyhow, if someone wants to be wallet maintainer, or maintainer of some other subsystem, let me know <-- wumpus: they should just step up? 19:42:07 like, ken2812221 looks like windows maintainer? 19:42:13 provoostenator: that's effectively how RTM is judged anyway 19:42:15 promag: good idea! 19:43:24 he's doing a great job with the windows unicode support 19:43:55 The important thing is actually doing the work, meaning taking a concerted effort to review and understand changes, their short and long term implications-- their impact on the users, network, rest of the code base, their historical context... along with sheparding things along to make sure the required stuff gets done (if not actually doing it themselves) 19:43:57 I'm—somewhat disappointed—that windows still needs so much platform-specific code, but it's better than breaking on non-english people's PCs 19:44:14 These are things that almost everyone can do more of. 19:44:43 gmaxwell: agree 19:45:23 if someone was doing the work then assigning someone a maintainer label was easy 19:45:33 that's how jonasschnelli became GUI maintainer, for ex. 19:45:35 So I think thats really an action item people can take from this discussion, look for oppturnityies do to more of that yourself, and to help others do the same. 19:46:26 yes 19:47:11 opportunities* 19:47:55 Were there any other topics? kind of a bummer of a meeting. :) 19:48:09 John had a third 19:48:29 I had one more quick one on archiving meeting notes (sorry - didn't mean to take up all the time. Thought they'd all be quick) 19:48:32 #topic archiving meeting notes 19:48:50 Botbotme is shutting down. not sure if anyone uses it 19:48:51 https://lincolnloop.com/blog/saying-goodbye-botbotme/ 19:48:52 jnewbery: well it needed to be said, Ithink 19:49:07 I know that the bitcoincore.org meeting notes summaries linked there at least 19:49:29 meeting notes also link to http://www.erisian.com.au/meetbot/bitcoin-core-dev/ , which I think is maintained by aj 19:49:54 it'd be a shame if that went away at some point. I wonder if it makes sense to keep a mirror of the meeting notes somewher in the project 19:50:07 we could have our own logger that publishes to bitcoincore.org? 19:50:10 Meeting notes or full channel log? 19:50:20 we have aj's logger right? 19:50:24 Both would be nice, but seperately. 19:50:32 meeting notes are most important I think, but yeah both 19:50:50 the meetingbot logs to www.erisian.com.au 19:51:11 as for summaries those should be part of the bitcoincore.org site itself not linked externally 19:51:27 yes, summaries are at bitcoincore.org 19:51:48 provoostenator: am I right in thinking you ran a logger at some point? 19:51:50 could also copy the logs there, I gues 19:52:02 would be good to have everything self-contained 19:52:09 meshcollider: I did, but no longer do 19:52:14 Ok 19:52:27 could we migrate aj's meetbot to bitcoincore.org? 19:52:47 BotBot server was fairly easy to deploy, so sounds like a good tool for this. 19:53:04 achow101: dunno, but could auto-copy the logs after a meeting 19:53:22 it'll print something like 19:53:22 21:52 < lightningbot> Minutes: http://www.erisian.com.au/meetbot/bitcoin-core-dev/2018/bitcoin-core-dev.2018-09-06-19.00.html 19:53:25 21:52 < lightningbot> Minutes (text): http://www.erisian.com.au/meetbot/bitcoin-core-dev/2018/bitcoin-core-dev.2018-09-06-19.00.txt 19:53:28 21:52 < lightningbot> Log: http://www.erisian.com.au/meetbot/bitcoin-core-dev/2018/bitcoin-core-dev.2018-09-06-19.00.log.html 19:53:33 so just a matter of copying those to bitcoincore.org and voila 19:54:15 Ideally could run both botbot and the meetbot on the bitcoincore.org server directly ? 19:54:18 Perhaps irc.bitcoincore.org could run such an instance? It's a much nicer format imo. 19:54:21 it needs to be checked into git so I don't think it can happen fully automatically 19:54:37 Different subdomain means you can skip the Github flow (initially). 19:54:38 wumpus: it could run in a sub domain 19:54:56 provoostenator: I would want to host random irc logs on the bitcoincore domain 19:55:19 Can be a completely separate trash.bitcoin-core-dev-logs.domain 19:55:21 these are only logs of the meeting 19:55:35 You can pick which channel(s) to log. Or are you worried even about what could end up in this channel? 19:55:36 re: cutting down on refactoring PRs: one option might be to add a policy that forces refactoring-only PRs to document how each changed git hunk is covered by tests. If no test exists, obviously the proposing contributor would have to write one. 19:55:48 oh you want to log the entire channel? 19:56:00 Yeah, I think it makes sense 19:56:04 BotBot currently does and I think that's worth keeping up 19:56:19 I think it currently makes more sense to log the entire channel with botbot going down 19:56:42 I've linked to botbot logs in Github tickets more than once. Whatever tool we use, being able to deep-link to a specific message is very nice. 19:56:50 jamesob: I think that's good policy for any change, yes 19:56:53 Agree 19:57:12 Can botbot be hosted on GitHub (or at least the assets?) 19:58:02 wumpus: my only reservation is that that's a pretty high burden for large changes from established contributors... but maybe that makes it even more worthwhile :) 19:58:04 it can't run from github 19:58:46 jamesob: the biggest issue here is the volume, not so much the changes themselves, many don't even change the compiled code or are obviously correct like removing an argument 19:59:00 Can it store the logs in a git repo? 19:59:03 jamesob: whichi s okay, but not of 5 of such PRs are opened every day 19:59:30 MarcoFalke: I'm sure you could turn the log directory into a git repo either way 19:59:46 MarcoFalke: sure, though if commits need to be signed :) 19:59:54 OTS? 20:00:15 wumpus: very much agreed. I was just thinking that such a policy (plainly advertised in a PR template, say) would filter out half-baked or lazy refactors (or at least allow a justified quick close) 20:00:16 when commigint to bitcoincore.org, really a human needs to be invovled 20:00:18 Don't need to sign the commits if they're just pushed to a separate meeting-log repo 20:00:26 If it is a binary blob (db) it might not work with git (or GitHub at least) 20:00:36 oh, no it's just text files 20:00:51 kewl 20:00:58 #endmeeting