19:00:04 #startmeeting 19:00:04 Meeting started Thu Apr 18 19:00:04 2019 UTC. The chair is wumpus. Information about MeetBot at http://wiki.debian.org/MeetBot. 19:00:04 Useful Commands: #action #agreed #help #info #idea #link #topic. 19:00:14 hi 19:00:17 hi 19:00:28 hi 19:00:33 #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 19:00:42 hi 19:00:46 hi 19:00:53 hi 19:00:55 hi 19:00:56 when rc4? 19:01:07 #topic 0.18.0rc4 19:01:21 I guess #15839 is holding it back 19:01:23 https://github.com/bitcoin/bitcoin/issues/15839 | [0.18] Revert GetData randomization change (#14897) by sdaftuar · Pull Request #15839 · bitcoin/bitcoin · GitHub 19:01:30 Needs merge 19:01:42 that seems to be the only one left? 19:01:54 yeah, after that I think we are good to tag rc4 19:01:59 good to know 19:02:09 oh I thought the revert was merged already. 19:02:38 ok, let's merge that one and tag rc4 after the meeting 19:02:43 ack 19:02:46 ack 19:02:50 #action merge 15839 and tag rc4 19:03:27 #topic High priority for review 19:03:39 https://github.com/bitcoin/bitcoin/pulls?q=is%3Aopen+is%3Apr+project%3Abitcoin%2Fbitcoin%2F8 6 PRs on there right now 19:04:33 anything to add/remove? I guess everyone does this outside of the meetings nowadays 19:04:48 can i have 15427? 19:04:59 #15427 19:05:01 https://github.com/bitcoin/bitcoin/issues/15427 | Add support for descriptors to utxoupdatepsbt by sipa · Pull Request #15427 · bitcoin/bitcoin · GitHub 19:05:02 can I have #15758? 19:05:04 https://github.com/bitcoin/bitcoin/issues/15758 | qa: Add further tests to wallet_balance by MarcoFalke · Pull Request #15758 · bitcoin/bitcoin · GitHub 19:05:05 i have a brief topic i'd like to cover after we go through other topics - an opportunity to meet with the github CEO and share feedback from this project 19:05:41 gwillen asked for #15024 to go in after the last wallet meeting 19:05:43 https://github.com/bitcoin/bitcoin/issues/15024 | Allow specific private keys to be derived from descriptor by meshcollider · Pull Request #15024 · bitcoin/bitcoin · GitHub 19:06:07 jnewbery: thanks, I was just trying to find that but I'm on an airplane with bad wifi 19:06:21 sipa MarcoFalke added 19:06:27 thx 19:06:40 thanks 19:07:03 also added 19:07:12 +1 thanks! 19:07:30 looks like both achow101 and sdaftuar have two PRs on the list now :o 19:07:45 oops 19:08:05 sdaftuar will resolve now 19:08:14 can/should we make a choice what to keep on there? 19:08:16 If they were suggested by different people, it should be fine 19:08:17 i propose a trial by combat to determine whose PRs remain 19:08:34 Everyone can suggest one pr (it doesn't have to be their own) 19:08:39 is your PR heavier than a duck 19:08:40 sipa:everyone gets to have one PR 19:08:51 MarcoFalke: hmm 19:08:57 instagibbs: how many lines of code does a duck weigh? 19:08:59 Yes, but based on who proposed. 19:08:59 MarcoFalke: that really hard to keep the overview 19:09:03 not who authored. 19:09:07 I don't really care but it's kind of getting out of hand 19:09:12 (or that was my understanding) 19:09:13 but I agree that achow101 and sdaftuar should pick one pull that stays 19:09:16 jonasschnelli: yeah, exactly 19:09:23 How do we keep track who proposed? 19:09:24 github doesn't track this 19:09:43 remove NOTFOUND for sdaftuar 19:09:44 let's remove #15741 for now. it needs to be rebased anyways 19:09:46 so are all 9 things on the list proposed by different people? 19:09:46 https://github.com/bitcoin/bitcoin/issues/15741 | Batch write imported stuff in importmulti by achow101 · Pull Request #15741 · bitcoin/bitcoin · GitHub 19:09:56 ok 19:10:29 thank you, done 19:10:30 In the future we can use some greppable line in IRC to record requests. 19:10:56 7 PRs on the list now, that's just about managebale 19:11:03 any other topics? 19:11:10 there are 4 19:11:14 moneyball: has a bunch 19:11:16 https://gist.github.com/moneyball/071d608fdae217c2a6d7c35955881d8a 19:11:24 We could also add a project column per non-author-proposer 19:11:36 I don't expect we would have a lot 19:11:44 moneyball: thanks 19:12:09 #topic Should send-to-non-v0-witness be standard (sipa) 19:12:15 hi 19:12:28 so we currently have two policy rules w.r.t. future segwit versions 19:12:51 one is an IsStandard one that makes sending _to_ a native segwit (bech32) future witness version nonstandard 19:12:52 jonasschnelli: it's unfortunate that it's not possible to add extra info to the 'cards' 19:13:07 the other is a script rule that makes spending any future witness version (incl. p2sh) nonstandard 19:13:35 i believe that first rule does more harm than good 19:14:05 The tradeoff is: if you make payments to bech32 addresses with 'future' segwit versions, should your payment get stuck (esp ugly for a send many or if your wallet has few inputs) OR should users be somewhat more exposed to stupidly sending to an insecure 'future' address. 19:14:09 I'm inclined to agree 19:14:18 I agree the first rule does more harm than good. 19:14:20 i suspect the reason is protecting users, but once the address is already created by the receiver it's already too late 19:14:34 so if we want that rule, i believe it belongs in the wallet, not in relay policy 19:14:36 No wallet should create thos addresses 19:14:47 (getting stuck is a problem because it locks up your change) 19:14:57 To the extent that it provides some real protection, it's mostly a protection against premature activation in wallets. 19:15:09 sipa: are you suggesting it should be wallet rule to not send to those addresses? 19:15:25 sdaftuar: i'm not sure about that; but it shouldn't be more than just wallet 19:15:30 ugh. 19:15:48 sipa: i think i can agree that it should not be a relay policy, but i'm skeptical of making it a wallet rule 19:15:57 Currently wallet will send to non-v0 segwit addresses, and mempool won't accept that transaction 19:16:06 I tend to agree, this selfs a self-sabotaging relay policy 19:16:21 sdaftuar: my point is, trying to guess the reason for this rule, if the rule is desirable, it should be in the wallet :) 19:16:22 I think we should have the opposite. Wallet shouldn't send to non-v0 segwit addresses, but mempool should accept and relay 19:16:26 tangent: if relay policy allows it, maybe it should always allow RBF on it? 19:16:50 jnewbery: note that it also doesn't work for p2sh embedded segwit, so it's a weak protection at best 19:16:52 jnewbery: if wallet doesn't send to such addresses, we will have a similar problem rolling out v1 segwit addresses as rolling out bech32 19:16:53 jnewbery: Or better, not restict it at all. Refusing to send to it harms forward compatiblity. 19:16:57 jnewbery: but isn't the whole point of Bech32's extensibility in this regard, so that we don't need to upgrade wallets to send to new versions? 19:17:17 luke-jr: yup 19:17:18 forward compatibility is kind of useful 19:17:22 Exactly... 19:17:23 and then we end back up with multiple years delay in deploying new functionality, which was what the versions were intended to address. 19:17:49 yeah, i think my preference is not having the rule in the first place 19:17:50 IMO allow relay and wallet, but force RBF opt-in ;) 19:17:59 delay in bech32 adoption is not caused by Bitcoin Core not supporting bech32 in pre v0.15 19:18:05 there's *tons* of ways to send coins into the void, I don't think doing this accidentally is anything more likely than sending to a non-existant classic address for ex. 19:18:06 So I also dont think the wallet should refuse to send either, a warning at most 19:18:08 it's caused by other wallets and exchanges in the ecosystem 19:18:15 We also, for example, don't prevent people from sending to 1JwSSubhmg6iPtRjtyqhUYYH7bZg3Lfy1T 19:18:23 jnewbery: what we do in Core's wallet should be the same as what other wallets ought to do 19:18:30 luke-jr: +1 19:18:43 which is not send to non-v0 until there is a defined v1 19:18:56 a warning would be okey 19:18:57 the fact that it's not a relay policy will lock up change 19:18:58 We certantly cannot argue that varrious parties are not doing the right thing if we won't do that thing ourselves 19:19:05 but I think we agree, this should not be relay policy 19:19:17 i'll PR removing it from relay policy 19:19:21 relay policy has never been used to protect users, if so, why no excessive fee check? 19:19:31 wumpus: exactly 19:19:31 indeed 19:19:32 wumpus: kinda one sec on that point. 19:19:33 sipa, it's worth a mailing list email? 19:19:35 I'm not saying we should never send to v1. Clearly we should change wallet policy when the node includes support for v1 19:19:55 wumpus: There is a non-protection argument too... we generally tend to not relay forward compatiblity features, in order to protect their future usage. 19:19:58 instagibbs: seems to be Core policy,... no need for ML?! 19:20:01 jnewbery: but then we could just as well make a new address format for every version 19:20:05 wumpus: but for _output types_ this doesn't apply. 19:20:11 gmaxwell:right 19:20:11 replace-by-version? :p 19:20:23 jnewbery: Wallet support to generate v1 addresses can always wait after the fork activated 19:20:26 jonasschnelli: it seems likely a topic other software would want to consider and act on too 19:20:27 actually 19:20:28 jonasschnelli, people may have made assumptions based on current policy, right or wrong? 19:20:32 luke-jr: that' not the same at all. This is a one-line (or config) or config 19:20:35 jnewbery: and then we will end up with multiple year delays after activation before v1 can be used by wallets. 19:20:38 this is a violation of BIP173 19:20:45 sipa: correct. 19:20:47 "Version 0 witness addresses are always 42 or 62 characters, but implementations MUST allow the use of any version. " 19:20:47 oh 19:21:02 it makes sense to inform people on the ML 19:21:08 so we need to change BIPS.md :p 19:21:15 The intentional and widely discussed design of BIP173 was to enable seemless use of future versions. 19:21:41 it doesn't need to be *discussed* there, IMO, but mentioning it so there is awareness is good 19:21:48 considering BIP173, it's arguably a bug to fix in backports even ;) 19:21:48 i believe this code actually predates bip173 19:21:58 sipa: it does. 19:21:59 heh 19:22:01 so is the change to allow sending to non-v0 but not relay transactions with non-v0 outputs? 19:22:10 wallets should send to any address a merchant provides them, but the wallet itself should only generate v1 addresses after the v1 fork activated 19:22:11 achow101: inputs*? 19:22:35 achow101: i'd just drop the rule entirely 19:22:47 MarcoFalke: I'd even wait at least >=100 blocks after , but that's another discussion 19:22:50 We need to not relay v1+ _spends_ in order to protect the activation of future v1+ rules. Outputs are fine. 19:22:53 maybe we want to independently add a warning in the GUI 19:23:03 achow101: outputs would be relayed, but spending from them would be non-standard 19:23:05 sipa: policy should prevent spending v1 UTXOs 19:23:13 luke-jr: it already does 19:23:14 ah, I see 19:23:16 sipa: nah, because of P2Sh stuff 19:23:34 sipa: yes, but it sounded like you might be talking about dropping it too 19:23:36 luke-jr: even P2SH-embedded v1 segwit output spends will not be relayed 19:23:48 ah no, i'm only talking about the sending to part 19:23:52 k 19:23:57 (which is implemented completely independently) 19:24:07 right thats another point against blocking v1 outputs: It's _impossible_ to block p2sh v1 outputs... 19:24:25 it would be nice to not bother implementing p2sh for v1, i think? 19:24:27 and because of ^, I don't think we should warn sending to v1 outputs either 19:25:01 sdaftuar: is there a benefit to that? 19:25:14 sdaftuar: nothing prevents anyone from making a p2sh with v1 as redeemscript though 19:25:16 that's an independent discussion 19:25:22 There are many ways people can hand you insecure addresses already... I at least don't have any reason to think that insecure future-version addresses are a worse problem than things like copy and pasting example addresses. 19:25:29 achow101, you can define it to be illegal tho 19:25:39 jnewbery: what's your opinion? 19:25:41 or just leave it undefined 19:25:43 sipa: agreed, but it drives the point home that we want v1 addresses to be forward compatible 19:25:46 achow101: we could, for example, close of p2sh embedded spending in the future entirely. 19:25:58 s/of/off/ 19:26:04 I still believe that the wallet shouldn't send to v1+ addresses until the node can validate them 19:26:23 jnewbery: what do you mean by validate them? 19:26:27 ^ 19:26:38 I think people upgrade Bitcoin Core fairly frequently in general, so I can't see this being something that holds up adoption of segwit v1 19:26:42 There normally isn't really any validation of outputs. 19:26:44 why does the sender care if the recipient spends it or not 19:26:45 I mean that they can be spent 19:27:11 sdaftuar, another point to doing that is then you *know* which version you're sending to, up to wallet to guard against edge cases 19:27:14 All other things being equal, I'd prefer the wallet not to be able to send to a class of unspendable addresses that we can easily check 19:27:23 jnewbery: the sender doesn't know if they can or can't be spent 19:27:27 jnewbery: would you be ok with a GUI-only warning? 19:27:29 so to be clear: the discussion is about the relay policy, the wallet is a different topic 19:27:39 for example, we don't send to v0 with non 42/64 character witnesses 19:27:45 (FWIW, most of my inbound peers are older versions... many old enough to have no bech32 support) 19:27:49 jnewbery: it is spendable, just rejected by policy 19:28:02 jnewbery: yes, because v0 is defined now. There is no forward compatiblity problem. 19:28:09 I'd be ok with anything. I'm just expressing an opinion, which it appears is minority :) 19:28:13 the wallet not being able to send to certain addresses doesn't nearly block forward compatiblity as much as a restrictive relay policy does 19:28:16 gmaxwell: relaying of v0 witness outputs was added in 0.13.0 though; long before bech32 was implemented 19:28:29 most nodes are 0.16 still 19:28:41 I think we should allow sending to v1+ in the wallet and in the GUI 19:28:50 Right, my opinion is that the forward-compatibility issue is not a huge issue 19:28:54 most newly syncing nodes I see are 0.16.1 ... fwiw. which it's own puzzle... 19:29:11 jnewbery: you mean not for relaying either? 19:29:18 0.16.1 is 50% of all nodes it looks like 19:29:19 forward compatibility seems to be more important than foot-gun that trigger very very rarely 19:29:25 No, I think we should relay sending to V anything 19:29:31 And we don't (and can't) prevent P2SH forms anyway 19:29:43 I'm confused now 19:30:01 I think we're all in agreement about mempool policy 19:30:03 so, do we agree on changing this relay policy? 19:30:09 yes 19:30:10 i think so 19:30:11 Yes 19:30:21 +1 19:30:25 ack 19:30:25 luke-jr: I think something weird is going on wrt versions, so that figure might be distored. (e.g. run your figures but exclude china...) 19:30:26 the only thing we disagree about is whether there should be a wallet check. I say yes, but I haven't convinced anyone :) 19:30:30 ok! 19:30:37 I guess the we are not agreeing about wether the wallet allows to send to v1+ 19:30:44 jnewbery: I think a warning makes sense 19:30:45 I'm ok with a wallet warning 19:30:50 gmaxwell: Chinese users are real though? 19:30:55 I think a warning is foolish. 19:31:01 me 2 19:31:13 if we could reliably warn, it might be worth considering, but we can't 19:31:16 luke-jr: Yes but I'm not confident that they're users. We can talk offline. 19:31:20 Assume one will send to v1 with 0.18.0 in one year where we assume having v1 19:31:22 becuase of p2sh etc 19:31:40 (if 0.18.0 would have the warning) 19:31:54 jonasschnelli: if warnings were reliable, we could base it on what we see in blocks 19:31:57 I could even see blocking sending, but only up until a certian time. 19:32:06 I'm sure users would send to the p2sh version of it just thy bypass the warning 19:32:10 eg, if we see a softfork deployment, and a bunch of v1 txs getting mined, then okay 19:32:28 But forever warning or blocking is just going to make it so that we can't quickly switch to v1 address generation by default. 19:32:29 luke-jr: yes. But that complex to implement without knowing the future 19:32:39 How would the warning be worded? 19:32:40 well, because we can't detect it reliably anyway, no point doing it even that way 19:33:05 I feel like the principle of outputs is being lost here. 19:33:08 (I suppose we could look for spends getting mined instead) 19:33:25 When a third party provides you with an output, thats it. It is none of your business what their policy is. 19:33:37 gmaxwell: i agree with that 19:33:42 This is one of the underlying principles behind p2sh and later hash based addresses. 19:33:55 gmaxwell: good point 19:33:58 "Warning: You are sending to an address that miners can steal from"? 19:33:59 It's an important principle because it lets the ecosystem evolve without everyone else getting up in your business. :P 19:33:59 We can't do anything when someone gives you a bcash address either 19:34:06 MarcoFalke: that might not be true though 19:34:09 Warning if the last blocks have no Vx output spent is probably an overkill? 19:34:15 And the the users go on reddit and ask what it means 19:34:18 MarcoFalke: that warning wouldn't be true after some point in the future. 19:34:35 s/can/may for a limited time/ 19:34:38 I'm not sure what warnings would achieve. 19:35:09 it would achieve people moving back to P2SH wrappers 19:35:13 lol 19:35:17 yuck! 19:35:22 and still sending to v1 19:35:24 :P 19:35:29 right 19:36:12 time for next topic, I think 19:36:16 +1 19:36:22 #topic Bitcoin Core design documentation (jnewbery) 19:36:25 instagibbs: good point on the bcash addresses. I've been told that this has been causing some pretty big nussances for some people (mostly the other direction, someone buys bcash thinks its bitcoin and sends it to an exchange bitcoin address....) 19:36:31 I'd prefer: "Warning: You are sending to a p2sh address" 19:36:48 gmaxwell, happens a lot, and actually forcing people onto bech32 would fix these since they have their own bch code thing 19:37:04 There are currently a lot of high-level design considerations that aren't documented in the codebase. Some of them may exist in individual contributor's gists, or might not be written down at all. 19:37:15 Should we try to have some standard location to put them in so it's easier for people to understand why things are the way they are? One suggestion would be to use github's wiki feature. 19:37:30 Examples: P2P banning/disconnecting design philosophy 19:37:35 jnewbery, ACK, but note that it's mostly me imagining other people doing the work 19:37:41 why not the doc folder? 19:37:46 Past critical bugs that have been fixed 19:37:49 we have that devwiki repo we use for release notes. could put other docs there 19:37:58 I also prefer within the sources 19:38:04 agree with wumpus. Should be in ./doc/ 19:38:10 Also,.. how do we prevent from getting outdated? 19:38:22 I'd prefer within the codebase, in particular because keeping a durable copy of github issues/wikis/etc is a lot more work. 19:38:24 jonasschnelli: Yell at people for not updating the docs 19:38:26 achow101:yes, that would be another option 19:38:33 I don't think adding docs should go through the same review process as code changes 19:38:36 Maybe put a boiler plate header on them that they could be outdated. 19:38:44 gmaxwell: github wikis are repos. You can clone them locally 19:38:47 and add a last updated date to each document or something. 19:38:51 jonasschnelli:same with anything else, it needs to be maintained or will be removed again at some point 19:39:06 jnewbery: yes they should. Wrong documentation is more harmful than no documentation 19:39:08 even having it in the history is useful too. 19:39:28 IMO it should be separate from the code. 19:39:37 but I like the idea, if anyone is willing to write this ata ll 19:39:47 this is an easy case to modularise; it has no ties to our versions/branches 19:39:49 i like the idea of putting a "Last updated at" + warning it could be outdated 19:39:55 MarcoFalke: wait what, wrong documentation is more harmful than nothing? can you explain? 19:40:21 I don't really care what repo its in, just should be in some repo for sure. :) 19:40:30 I'm not suggesting that someone goes and writes a bunch of documentation. I'm suggesting that people who want to contribute documentation should have somewhere to put it. 19:40:41 to motivate this, things like p2p design are basically in the heads of a handful of people, I've never seen it written down anywhere aside from IRC 19:40:54 sdaftuar: because it gets people to waste time, thinking of solutions based on the documentation, then it doesn't really apply to the current code base anymore 19:41:04 sdaftuar: I was talking about review 19:41:09 sdaftuar: I'm also of the view that wrong documentation can be worse than nothing. ::shrugs:: it isn't always. Depends on the recipent and how the wrong doc was written. 19:41:11 not about outdated documentation 19:41:21 (okay maybe not also) 19:41:28 wumpus: MarcoFalke: i definitely believe in review, but i imagine that mostly you're better off with old docs, rather than no docs 19:41:38 But I still think it's worth doing even if it ends up outdated. 19:42:05 wrong code comments can cause a lot of damage, maybe less so for high level docs 19:42:09 Its just somewhat important the the text itself reflect the possibility of it being outdated. 19:42:18 agree that outdated (timestamped) documentation is helpful 19:42:27 anyway i would certainly appreciate having a place to put docs that i have written, so if we can decide to put stuff like that anywhere, i will happily contribute 19:42:29 An argument for a wiki and not in the PR is that we won't get a bunch of helpful new contributors opening PRs to fix spelling in the docs 19:42:51 well, put it in the wiki then 19:42:54 *not in the repo 19:42:59 everyone has write access to that one :) 19:43:06 Is a bunch of spelling fixes important? :P 19:43:11 github wikis are just git repos 19:43:17 I don't think it exists for bitcoin/bitcoin 19:43:19 gmaxwell:not important, but I agree re: PR bottlenecks 19:43:20 which is the downside that anyone can vandalize 19:43:26 jnewbery: it doesn't for access control 19:43:31 jnewbery: please use the devwiki 19:43:34 how hard is it to run a spellchecker these days? 19:43:36 https://github.com/bitcoin-core/bitcoin-devwiki/wiki 19:43:39 MarcoFalke: can address that when/if it happens 19:43:47 ok 19:43:52 why not a wiki in bitcoin/bitcoin? 19:44:00 jnewbery: because it's Core-specific? 19:44:02 because it'd only be writabel by people with commit access 19:44:06 ah 19:44:06 (and if it isn't, we have BIPs) 19:44:08 we could also see from time to time whether a wiki article is sufficiently mature and stable to include it in the doc/ directory directly 19:44:19 Also be careful with making publically writable stuff in bitcoin/bitcoin. 19:44:19 the only way to do delegation on github is to have multiple repos 19:44:32 gmaxwell: yes, I don't want that 19:44:42 gmaxwell: indeed 19:44:44 "ATTENTION. OLD BITCOIN IS VULNERABLE. DOWNLOAD HOTFIX NOW http://secure.haxor.com/bitcoin.exe" 19:44:55 hmmm 19:44:56 ouch :( 19:45:00 no need to throw everything in the same place 19:45:01 heh 19:45:12 ok, thanks. Sounds like https://github.com/bitcoin-core/bitcoin-devwiki/wiki is the place 19:45:15 gmaxwell: 404 19:45:23 lol 19:45:25 15 minutes left. Next topic 19:45:27 rofl 19:45:40 but wait, I need to get the hotfix! 19:45:44 luke-jr: "wine : 404" 19:45:49 #topic opportunity to provide feedback with GitHub CEO (moneyball) 19:46:01 you gotta add sudo 19:46:06 moneyball is github ceo? 19:46:07 so jimpo and i received an email from a guy at github: I run a program for our CEO Nat Friedman connecting him with community members in GitHub. It’s an hour long chat on Friday’s where you can talk about anything GitHub that’s on your mind. I was wondering if you all would like to join us. You’re welcome to bring other maintainers up to a max of about 7 people. Many groups bring a “top 10” list with 19:46:07 them and we go through that. We also have some demos and mockups of stuff to show and then discuss. Tell us how to improve GitHub. 19:46:18 (I don't really have anything to discuss wrt hardcoded seeds at the moment) 19:46:25 wumpus: you can allow anyone to edit the wiki, not just those with write access, but yeah thats a problem in itself 19:46:39 wumpus: ok 19:46:43 moneyball, sorry who is "we" wrt demos 19:46:52 moneyball: +1! There's something that we've been discussing in a separate thread, this would be a great opportunity. 19:47:04 This is an opportunity for the project to communicate 1) annoying bugs/reliability issues 2) new feature requests 3) maybe what it would take for the project to be comfortable using GitHub long-term 19:47:06 sounds good for people with opinions. :) 19:47:07 (we=DCI) 19:47:32 I am happy to attend this but (a) we need to compile a list (b) it would really be better if at least 1 other dev joined me who has deeper experience with the top 10 list than I do 19:47:33 instagibbs: lol, sorry, that wasn't in response to you. 19:47:34 open source github? :p 19:47:42 feature request: Nicely display pgp signed comments 19:47:47 meshcollider: maybe, but once you want to lock down access, the only mechanism is the list of people with write access to the repo, which is the people with commit access 19:47:52 luke-jr: i'd say nothing is off-limits! 19:48:00 MarcoFalke: eh, trusting GitHub to verify PGP seems like a bad idea 19:48:12 Just display, not verifying 19:48:12 Probably interested people should form a list of feature requests and/or bugs (gist or wiki) 19:48:13 stop having commits reported in git commit timestamp order :P 19:48:16 instagibbs: "we" is github 19:48:25 No need to post your feature request here and now 19:48:31 yeah 19:48:32 instagibbs: that's git-log's default too though 19:48:37 yeah i am not intending to create the list right now in this meeting 19:48:48 moneyball: Thanks and great opportunity I agree 19:48:53 moneyball: I'd be interested. 19:48:54 i wanted to see if others view this as a valuable opportunity and whether 1 or more folks would join me 19:48:55 if someone makes a list I'll dump some gripes in and other people can decide if they agree or think they're important. 19:48:58 instagibbs: yes for the love of god, displaying commits in topo instead of timestamp order 19:49:06 there has been an open issue on this for a fucking age 19:49:10 It is in-person right, not remote attendance? 19:49:52 (for reference https://github.com/isaacs/github/issues/386) 19:49:56 an in-person lunch in SF 19:50:34 gwillen: --graph would be nice too :p 19:50:44 let's not ask for a pony here ;-) 19:50:47 gwillen: yes please 19:50:51 maybe open an issue on our tracker, where people can comment with things to mention? 19:51:01 (also, ack topo sort; i've personnally asked them for this years ago) 19:51:02 +1 instagibbs suggestion 19:51:37 yes please! 19:51:38 sipa: i will do that 19:51:48 what I"d like is to be able to do finer permission control, e.g. be able to give people access to issues/PR management without giving them write and merge access to the repo 19:52:13 moneyball: thanks 19:52:15 if anyone would like to join cfields and me, let me know so we can coordinate a date with GitHub 19:52:33 wumpus: maybe github rejecting pushes that don't pass the checker script is sufficient 19:52:39 in the mean time please contribute to the Issue i'll create. i'll post it here once created. 19:52:53 Sounds good 19:53:04 I think it'd be most useful for us to discuss things that are paranoia-related, since that's what's most interesting about us to them, I'd think. 19:53:13 luke-jr: well if 'checker script' is sufficiently general, sure, though I wouldn't want to include the entirety of travis in there, such a check needs to be fast 19:53:19 Things like "display order" they'll hear from everyone. 19:53:35 my github feature request would be ability to base prs on top of other prs (just hide commits from base pr) 19:53:37 wumpus: eg, just the PGP checks 19:53:39 They should hear it from everyone! 19:53:55 ryanofsky: ooh, good idea 19:53:56 I'd like a better "boomark this PR" system to keep track of interesting PRs I want to come back to 19:53:59 luke-jr: that was exactly my thought. 19:54:03 cfields: good point 19:54:12 (re enforce pgp allowing for access split) 19:54:13 paranoid-mode would probably exclude using github 19:54:15 ok, maybe s/paranoia-related/related to the way we use github uniquely/ 19:54:19 cfields: i suspect the ways in which we most _differ_ from other projects is in centralization/trust concerns 19:54:30 sipa: yes, right. 19:54:31 jonasschnelli:yes, I think that's a very slippery slope :) 19:54:34 cfields: that makes sense, but on the other hand they have been ignoring the display order thing for almost 5 years 19:54:38 any other topics? 19:54:45 6 min left 19:54:48 gwillen: thre just may be an arch reason as to why its hard. 19:54:49 one thing I would find useful: a way for email notifications to distinguish between general project stuff, and stuff specifically I'm invovled in, and stuff I'm specifically mentioned in 19:54:49 don't think so 19:54:50 so if they're literally asking us for feedback, it would be good to say "why are you ignoring community feedback, please listen to it" 19:55:26 right now I often just ignore github notifications in bulk because there's so many, and don't see when people ask me things 19:55:34 luke-jr, i think that already exists, you can filter based on to address 19:55:36 luke-jr:there is, you acn filter on author@github.com and things like that 19:55:41 moneyball: maybe you can provide some context for why they reached out to us specifically? 19:55:57 I mean. there is a lot of little stuff, like they were totally unable to keep randos from taking over the attribution on imported commits, but we eventually 'fixed' that by creating a dummy account. I don't think this is worth discussing, since we 'fixed it' but its still kind of embarassing on their part. 19:56:04 jimpo and i had emailed them previously during the unicorn days, so our same contact reached back out to us 19:56:08 wumpus: I don't understand 19:56:24 But never forget, they need community feedback to improve to earn money for corporate customers 19:56:32 *from 19:56:33 luke-jr, if you want to filter mentions look for Mention in To: header 19:56:34 gmaxwell: I definitely agree on focusing on active problems with no good workaround 19:56:37 luke-jr there's a special to-address they'll add in those cases fornmentions 19:56:42 moneyball: heh, gotcha. Thanks. 19:56:47 hmm 19:57:44 #endmeeting