19:00:05 <wumpus> #startmeeting
19:00:05 <lightningbot> 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 <lightningbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
19:00:06 <MarcoFalke> Would have to remove the #include of libssl as well?
19:00:13 <MarcoFalke> oh meeting
19:00:16 <wumpus> MarcoFalke: yep
19:00:17 <provoostenator> hi
19:00:24 <promag> hi
19:00:36 <MarcoFalke> I wonder if it is possible to build openssl with just libcrypto and not libssl
19:01:17 <jnewbery> hi
19:01:50 <wumpus> any proposed topics?
19:01:54 <jonasschnelli> hi
19:01:59 <meshcollider> Hi
19:02:04 <MarcoFalke> Have we had issues reported for rc3 of 0.17.0?
19:02:22 <provoostenator> MarcoFalke: probably not: https://github.com/openssl/openssl/issues/4597
19:02:58 <wumpus> MarcoFalke: I don't think so
19:02:59 <achow101> hi
19:03:07 <achow101> MarcoFalke: there was that thing sipa pointed out
19:03:09 <achow101> with psbt
19:03:19 <achow101> #14196
19:03:20 <gribble> 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 <achow101> I'm not sure if it is necessarily a bug, it is annoying though when encountered
19:04:11 <promag> regarding missing pieces for multi wallets, hope to get #13100 and #13339 done shortly
19:04:14 <gribble> https://github.com/bitcoin/bitcoin/issues/13100 | gui: Add dynamic wallets support by promag · Pull Request #13100 · bitcoin/bitcoin · GitHub
19:04:16 <gribble> 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 <MarcoFalke> Ok, we should put that up as high priority and then target rc4 end of next week?
19:05:01 <wumpus> yes, good idea
19:05:08 <sipa> i encountered this issue while actually trying to use psbt btw :)
19:05:23 <MarcoFalke> 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 <wumpus> MarcoFalke: huh didn't I add those?
19:05:50 <wumpus> last week was like a blur
19:06:03 <sipa> still too busy this week, but if someone could add scantxoutset to the release notes?
19:06:49 <wumpus> yes I actually added the PRs and authors: https://github.com/bitcoin-core/bitcoin-devwiki/wiki/0.17.0-Release-notes
19:06:54 <MarcoFalke> wumpus: Thx. I've misssed yesterdays commit
19:08:22 <jonasschnelli> Anyone up for writing a short part about scantxoutset for the 0.17 release notes?
19:08:27 <wumpus> as for sharing the script, if you don't mind it's a mess, will push it into devtools soon
19:09:25 <promag> I can give a try to scantxoutset release notes
19:09:46 <wumpus> promag: thanks!
19:10:09 <jnewbery> some quick proposed topics: refactor/linter PRs , wallet maintainer , archiving meeting notes
19:10:37 <jonasschnelli> promag: thanks!
19:11:10 <wumpus> added 14197 to high prio
19:11:32 <promag> #14197
19:11:34 <gribble> 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 <wumpus> #topic refactor/linter PRs
19:11:56 <wumpus> stop it stop it stop it stop it stop it stop it stop it stop it
19:11:58 <wumpus> thx :p
19:12:07 <jnewbery> I think a lot of people get the sense that there are a lot of refactor/linter PRs these days
19:12:50 <wumpus> yes, it's too often
19:12:53 <jnewbery> 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 <achow101> wumpus: unfortunately practicalswift isn't here to hear that
19:13:05 <meshcollider> Lol
19:13:15 <promag> we can write a lint to prevent new linters with grep
19:13:58 <gmaxwell> 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 <wumpus> 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 <provoostenator> I like linters and other techniques to produce code consistentency, but obviously it shouldn't be become an obsession.
19:14:24 <wumpus> it's becoming an obsession for me (in the negative sense)
19:14:31 <gmaxwell> 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 <wumpus> if this keeps up, I'll close them blindly
19:14:42 <ryanofsky> i don't understand why you can't just tag them and look at the tag once a month
19:14:47 <provoostenator> Maybe someone should just combine them all in one giant lint PR and come back in a few months?
19:15:08 <wumpus> who doesn't he do that himself though?
19:15:17 <gmaxwell> ryanofsky: because 'when you look' doesn't change the fact that there is a review/correctness burden.
19:15:35 <wumpus> because some of us actually have to look at the list of allPRs and this is really discouraging
19:15:50 <jnewbery> 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 <wumpus> yes, please
19:16:53 <MarcoFalke> ryanofsky: They show up in the list of pulls by default
19:16:58 <promag> however those monthly cleanups can be bigger and harder to merge
19:17:49 <gmaxwell> 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 <MarcoFalke> Can we add a pull request GitHub template that asks for clear motivation of the changes?
19:18:05 <wumpus> 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 <wumpus> all proposed changes end up in one big list
19:18:43 <MarcoFalke> I.e. The changes need to improve user experience or significantly improve developer experience
19:18:59 <gmaxwell> 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 <wumpus> e.g. https://blog.ffwll.ch/2017/08/github-why-cant-host-the-kernel.html
19:19:11 <jnewbery> 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 <jonasschnelli> should we submodule the test system?
19:19:21 <gmaxwell> MarcoFalke: I also was thinking about articulate the benefit.
19:19:28 <meshcollider> wumpus: that's the point of GitHub "projects" isn't it
19:19:47 <gmaxwell> er, directing people to articulate the benefit.
19:19:52 <MarcoFalke> yeah ^
19:19:59 <wumpus> 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 <gmaxwell> 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 <wumpus> jnewbery: this is not a technical issue about separation in the source tree, Linux is also one big tree
19:20:54 <jnewbery> wumpus: I'll read the danvet post
19:20:56 <wumpus> it's just that top-level PRs don't really scale
19:21:28 <wumpus> I can't manually, humanly, handle 200+ PRs, sorry
19:21:55 <jnewbery> proposed topic: wallet maintainer
19:22:03 <MarcoFalke> I have seen that practicalswift also runs a bot(?) to comment on pull request directly with feedback harvested from clang-tidy
19:22:04 <wumpus> and if it keeps going like this, at some point it's going to break down
19:22:18 <MarcoFalke> I think these are more useful than linters
19:22:40 <sipa> i plan to do more wallet work soon, to push descriptors and other things forward
19:22:43 <wumpus> so we need a different way of woring
19:22:59 <sipa> now i have to run, sorry; will be back next week
19:23:08 <wumpus> later sipa
19:23:08 <promag> o/
19:23:37 <promag> MarcoFalke: agree ^
19:24:21 <wumpus> #topic wallet maintainer
19:25:04 <wumpus> MarcoFalke> I.e. The changes need to improve user experience or significantly improve developer experience <- yes
19:25:25 <MarcoFalke> ok, will write up something today
19:25:34 <MarcoFalke> sipa is gone, so let's assign him to be wallet maintainer?
19:25:46 <gmaxwell> ACK.
19:25:50 <achow101> +1
19:25:51 <sdaftuar> i thought we already did that
19:25:53 <jnewbery> 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 <meshcollider> I feel like he has already been assigned that role many times
19:26:03 <wumpus> 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 <promag> vote jnewbery for wallet maintainer :P
19:26:11 <jnewbery> promag: -1
19:26:25 <provoostenator> What is the wallet maintainer job description?
19:26:25 <wumpus> it's like a game of hot potato
19:26:29 <MarcoFalke> jnewbery: I am not aware of any single person that really knows what is going on in the wallet
19:26:47 <pierre_rochard> ryanofsky?
19:26:50 <jnewbery> MarcoFalke: that makes everyone equally qualified
19:26:51 <wumpus> provoostenator: review and merge wallet changes
19:26:55 <gmaxwell> sipa is closest, mostly as a side effect of knowing everything.
19:27:00 <wumpus> provoostenator: (most importantly, understand them)
19:27:22 <jonasschnelli> I think sipa is kinda the wallet maintainer... or am I wrong?
19:27:24 <jnewbery> 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 <provoostenator> Well, some degree of not understanding can be compensated by not merging without ACK's from people who do.
19:27:45 <wumpus> yes, exactly jnewbery
19:27:51 <jnewbery> and it's only 15k lines of code. How difficult can it be?
19:27:54 <wumpus> it's a matter of judgement I guess
19:28:00 <gmaxwell> jnewbery: tada, disqualified. :P
19:28:23 <achow101> jnewbery: I think it's a bit cleaner now with accounts gone
19:28:32 <achow101> less idiotic to understand
19:28:45 <wumpus> it's not even that bad if you dn't fully understand it now, if you're willing to learn it
19:29:01 <MarcoFalke> 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 <jnewbery> 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 <wumpus> yes, getting rid of accounts did make it less crazy
19:29:18 <jnewbery> It seems that waiting around for someone to volunteer or step up hasn't really worked
19:29:28 <gmaxwell> 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 <wumpus> I wonder how Linus picks subsystem maintainers
19:29:52 <wumpus> though, I guess, people actually volunteer
19:29:55 <gmaxwell> 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 <jnewbery> gmaxwell: we're still too bottlenecked on wumpus
19:30:16 <meshcollider> Make a large wallet PR and the first person GitHub picks as a "suggested reviewer" is the new maintainer
19:30:18 <wumpus> jnewbery: yes
19:30:29 <jnewbery> so we need to make a wumpus bot or delegate to maintainers
19:30:31 <gmaxwell> Github just doesn't really directly facilitate that kind of workflow.
19:30:39 <wumpus> ideally I could just leave for a bit and things would continue
19:30:50 <promag> honestly I think jnewbery has done a great job cleaning and maintaining and improving wallet code
19:31:00 <achow101> the solution is to just upload wumpus's mind and then start 20 instances of him :p
19:31:05 <gmaxwell> 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 <wumpus> achow101: yes!
19:31:16 <provoostenator> I'd be fine with jnewbery doing this as well.
19:31:37 <meshcollider> jnewbery: in all honesty, would you not want the role
19:31:41 <wumpus> me too
19:31:42 <jamesob> instagibbs seems to know wallet pretty well
19:31:44 <gmaxwell> it's not like there is an actual technical physical bottleneck on wumpus.
19:31:59 <jnewbery> I'm flattered, honestly, but already too busy with bitcoin optech, residency stuff, etc
19:32:31 <jnewbery> perhaps something for discussion in tokyo
19:32:40 <MarcoFalke> I think the bottleneck is not clicking the merge button (any of the 4 maintainers can do this)
19:32:52 <MarcoFalke> The bottleneck is review and signing off on the merge
19:32:59 <MarcoFalke> (when ready)
19:33:12 <wumpus> yes, which is not always an easy judgement, but still
19:33:19 <provoostenator> So it's more like a "sudo ACK"?
19:33:37 <gmaxwell> 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 <wumpus> if you know a certain part of the code well enough you could be maintainer of it
19:33:53 <wumpus> like, in Linux, if you wrote a certain driver, you're pretty much maintainer of it by default
19:34:10 <gmaxwell> the high priority PRs things helps, at least as we close for a release...
19:34:26 <MarcoFalke> 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 <MarcoFalke> So have more than one wallet maintainer
19:34:37 <wumpus> well the maintainer of a subsystem would also curate prioriteit
19:34:47 <wumpus> the problems seems to be finding people, *NOT* finding things for them to do :)
19:34:49 <achow101> MarcoFalke: isn't that the point of ACK's though?
19:34:54 <meshcollider> MarcoFalke: isn't that basically just an ACK then
19:35:03 <promag> right achow101
19:35:20 <MarcoFalke> Not every ACK means merge
19:35:39 <gmaxwell> 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 <MarcoFalke> more like the "sudo ACK" (provoostenator)
19:35:42 <wumpus> well it's more subtle than that, otherwise it  could jsut be a bot
19:36:08 <MarcoFalke> In the future I want it to be done by a bot, but thats a differnt topic
19:36:10 <wumpus> you also have to have a feeling who is the right person to ACK something
19:36:21 <wumpus> which would be possible if someone was a maintainer of that subsystem
19:36:30 <provoostenator> 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 <wumpus> but we're circling around
19:36:42 <gmaxwell> 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 <meshcollider> provoostenator: mo
19:36:46 <meshcollider> No*
19:36:54 <wumpus> gmaxwell: righ
19:37:21 <wumpus> anyhow, if someone wants to be wallet maintainer, or maintainer of some other subsystem, let me know
19:37:30 <clarkmoody> provoostenator: maintainers.md
19:37:51 <wumpus> clarkmoody: yep
19:37:56 <provoostenator> Ok, that works.
19:38:07 <wumpus> you can define a path there, and who is maintainer, I think github even parses it somehow
19:38:22 <promag> and what should a maintainer do? :P
19:38:25 <meshcollider> 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 <meshcollider> In*
19:38:56 <provoostenator> https://blog.github.com/2017-07-06-introducing-code-owners/
19:38:58 <gmaxwell> I think we should all act as though we were the maintainers of things more.
19:39:04 <jnewbery> meshcollider: yes, I think so
19:39:20 <wumpus> 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 <gmaxwell> 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 <gmaxwell> I think the issue wumpus struggles with is in part because no one is doing the job already.
19:40:02 <gmaxwell> :)
19:40:30 <gmaxwell> If someone were, it would be both less of an issue, and an easier thing to decide.
19:41:10 <wumpus> 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 <provoostenator> 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 <wumpus> but it's not given that I will be doing this forever
19:41:49 <promag> 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 <promag> like, ken2812221 looks like windows maintainer?
19:42:13 <meshcollider> provoostenator: that's effectively how RTM is judged anyway
19:42:15 <wumpus> promag: good idea!
19:43:24 <wumpus> he's doing a great job with the windows unicode support
19:43:55 <gmaxwell> 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 <wumpus> 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 <gmaxwell> These are things that almost everyone can do more of.
19:44:43 <wumpus> gmaxwell: agree
19:45:23 <wumpus> if someone was doing the work then assigning someone a maintainer label was easy
19:45:33 <wumpus> that's how jonasschnelli became GUI maintainer, for ex.
19:45:35 <gmaxwell> 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 <wumpus> yes
19:47:11 <gmaxwell> opportunities*
19:47:55 <gmaxwell> Were there any other topics? kind of a bummer of a meeting. :)
19:48:09 <meshcollider> John had a third
19:48:29 <jnewbery> 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 <wumpus> #topic archiving meeting notes
19:48:50 <jnewbery> Botbotme is shutting down. not sure if anyone uses it
19:48:51 <jnewbery> https://lincolnloop.com/blog/saying-goodbye-botbotme/
19:48:52 <wumpus> jnewbery: well it needed to be said, Ithink
19:49:07 <jnewbery> I know that the bitcoincore.org meeting notes summaries linked there at least
19:49:29 <jnewbery> meeting notes also link to http://www.erisian.com.au/meetbot/bitcoin-core-dev/ , which I think is maintained by aj
19:49:54 <jnewbery> 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 <achow101> we could have our own logger that publishes to bitcoincore.org?
19:50:10 <meshcollider> Meeting notes or full channel log?
19:50:20 <wumpus> we have aj's logger right?
19:50:24 <gmaxwell> Both would be nice, but seperately.
19:50:32 <jnewbery> meeting notes are most important I think, but yeah both
19:50:50 <wumpus> the meetingbot logs to www.erisian.com.au
19:51:11 <wumpus> as for summaries those should be part of the bitcoincore.org site itself not linked externally
19:51:27 <jnewbery> yes, summaries are at bitcoincore.org
19:51:48 <meshcollider> provoostenator: am I right in thinking you ran a logger at some point?
19:51:50 <wumpus> could also copy the logs there, I gues
19:52:02 <wumpus> would be good to have everything self-contained
19:52:09 <provoostenator> meshcollider: I did, but no longer do
19:52:14 <meshcollider> Ok
19:52:27 <achow101> could we migrate aj's meetbot to bitcoincore.org?
19:52:47 <provoostenator> BotBot server was fairly easy to deploy, so sounds like a good tool for this.
19:53:04 <wumpus> achow101: dunno, but could auto-copy the logs after a meeting
19:53:22 <wumpus> it'll print something like
19:53:22 <wumpus> 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 <wumpus> 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 <wumpus> 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 <wumpus> so just a matter of copying those to bitcoincore.org and voila
19:54:15 <meshcollider> Ideally could run both botbot and the meetbot on the bitcoincore.org server directly ?
19:54:18 <provoostenator> Perhaps irc.bitcoincore.org could run such an instance? It's a much nicer format imo.
19:54:21 <wumpus> it needs to be checked into git so I don't think it can happen fully automatically
19:54:37 <provoostenator> Different subdomain means you can skip the Github flow (initially).
19:54:38 <achow101> wumpus: it could run in a sub domain
19:54:56 <MarcoFalke> provoostenator: I would want to host random irc logs on the bitcoincore domain
19:55:19 <MarcoFalke> Can be a completely separate trash.bitcoin-core-dev-logs.domain
19:55:21 <wumpus> these are only logs of the meeting
19:55:35 <provoostenator> You can pick which channel(s) to log. Or are you worried even about what could end up in this channel?
19:55:36 <jamesob> 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 <wumpus> oh you want to log the entire channel?
19:56:00 <MarcoFalke> Yeah, I think it makes sense
19:56:04 <meshcollider> BotBot currently does and I think that's worth keeping up
19:56:19 <achow101> I think it currently makes more sense to log the entire channel with botbot going down
19:56:42 <provoostenator> 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 <wumpus> jamesob: I think that's good policy for any change, yes
19:56:53 <meshcollider> Agree
19:57:12 <MarcoFalke> Can botbot be hosted on GitHub (or at least the assets?)
19:58:02 <jamesob> 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 <wumpus> it can't run from github
19:58:46 <wumpus> 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 <MarcoFalke> Can it store the logs in a git repo?
19:59:03 <wumpus> jamesob: whichi s okay, but not of 5 of such PRs are opened every day
19:59:30 <meshcollider> MarcoFalke: I'm sure you could turn the log directory into a git repo either way
19:59:46 <wumpus> MarcoFalke: sure, though if commits need to be signed :)
19:59:54 <provoostenator> OTS?
20:00:15 <jamesob> 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 <wumpus> when commigint to bitcoincore.org, really a human needs to be invovled
20:00:18 <meshcollider> Don't need to sign the commits if they're just pushed to a separate meeting-log repo
20:00:26 <MarcoFalke> If it is a binary blob (db) it might not work with git (or GitHub at least)
20:00:36 <wumpus> oh, no it's just text files
20:00:51 <MarcoFalke> kewl
20:00:58 <wumpus> #endmeeting