19:00:00 <wumpus> #startmeeting 
19:00:00 <core-meetingbot> Meeting started Thu Apr 22 19:00:00 2021 UTC.  The chair is wumpus. Information about MeetBot at https://bitcoin.jonasschnelli.ch/ircmeetings.
19:00:00 <core-meetingbot> Available commands: action commands idea info link nick
19:00:11 <meshcollider> hi
19:00:16 <hebasto> hi
19:00:17 <luke-jr> hi
19:00:18 <gleb> Hi
19:00:21 <ariard> hi
19:00:21 <jnewbery> hi
19:00:25 <michaelfolkson> hi
19:00:27 <wumpus> #bitcoin -core-dev Meeting: achow101 aj amiti ariard bluematt cfields Chris_Stewart_5 digi_james dongcarl elichai2 emilengler fanquake fjahr gleb glozow gmaxwell gwillen hebasto instagibbs jamesob jb55 jeremyrubin jl2012 jnewbery jonasschnelli jonatack jtimon kallewoof kanzure kvaciral lightlike luke-jr maaku marcofalke meshcollider michagogo moneyball morcos nehan NicolasDorier paveljanik
19:00:29 <wumpus> petertodd phantomcircuit promag provoostenator ryanofsky sdaftuar sipa vasild wumpus
19:00:31 <glozow> hi
19:00:34 <jeremyrubin> hi
19:01:07 <wumpus> one proposed meeting topic for today: adding a second BIP editor (jnewbery)
19:01:20 <achow101> hi
19:01:26 <luke-jr> Great idea, but this is neither an appropriate time nor venue for that discussion.
19:01:27 <wumpus> any last minute topic proposals?
19:01:28 <MarcoFalke> #proposedmeetingtopic 0.20.2
19:02:23 <wumpus> #topic High priority for review
19:02:24 <core-meetingbot> topic: High priority for review
19:02:42 <wumpus> https://github.com/bitcoin/bitcoin/projects/8  has 10 blockers, no bugfixes and nothing chasing concept ACK
19:02:56 <wumpus> anything to add / remove or that is ready to merge?
19:03:42 <ariard> #19160 has 5 acks
19:03:44 <gribble> https://github.com/bitcoin/bitcoin/issues/19160 | multiprocess: Add basic spawn and IPC support by ryanofsky · Pull Request #19160 · bitcoin/bitcoin · GitHub
19:04:04 <jonatack> hi
19:04:10 <wumpus> ariard: good to know, thanks
19:04:11 <jonatack> may i add #21261?
19:04:12 <gribble> https://github.com/bitcoin/bitcoin/issues/21261 | p2p: update inbound eviction protection for multiple networks, add I2P peers by jonatack · Pull Request #21261 · bitcoin/bitcoin · GitHub
19:04:52 <wumpus> jonatack: added!
19:04:59 <jonatack> thanks!
19:05:20 <yanmaani> MarcoFalke: How do I do that, while adding them to the keypool?
19:05:36 <wumpus> yanmaani: meeting in progress, please delay other discussion until after it
19:05:44 <yanmaani> I can import public keys with importmulti, but that doesn't support adding private keys as change
19:05:59 <jnewbery> yanmaani: after meeting, please
19:06:55 <wumpus> #topic Adding a second BIP editor (jnewbery)
19:06:55 <core-meetingbot> topic: Adding a second BIP editor (jnewbery)
19:07:12 <jnewbery> hi
19:07:20 <jnewbery> luke-jr has been the sole BIP editor for several years, and it seems like he's now overstretched and only able to look at the repo about once a month
19:07:42 <jnewbery> I suggest that we lighten his load by adding a second BIP editor. BIP2 allows multiple BIP editors and refers to plural BIP editors in several places, eg "The BIP editors are intended to fulfill administrative and editorial responsibilities. The BIP editors monitor BIP changes, and update BIP headers as appropriate."
19:07:54 <wumpus> would make sense imo
19:08:00 <jnewbery> kallewoof has recently offered to help with BIP repo maintainence:
19:08:00 <jnewbery> 15:43 < kallewoof> luke-jr: on a serious note, if you want help with the bip maintenance stuff, i'll gladly assist.
19:08:19 <jnewbery> If he's willing, I propose that add him as a second BIP editor.
19:08:30 <achow101> Seems like something to discuss on the mailing list really
19:08:35 <luke-jr> ^
19:08:39 <MarcoFalke> ACK, but seems off topic for this channel
19:08:56 <sipa> i agree with jnewbery's idea, but ut's something to discuss on the ML
19:09:01 <jnewbery> Lots of us know kallewoof. I believe he's trustworthy and perfectly capable of fulfilling the required administrative and editorial responsibilities.
19:09:26 <ariard> i agree on the motivation but same something to discuss on the ml
19:09:27 <wumpus> it's something to *decide* on the ML, but it's fine to discuss it here once imo
19:09:34 <luke-jr> FWIW, I did discuss it further with kalle privately; but IMO the timing is very poor for adding another editor right now
19:09:45 <MarcoFalke> luke-jr: why?
19:09:46 <jnewbery> luke-jr: why is the timing poor?
19:10:22 <luke-jr> it seems motivated by an effort to give special treatment to a certain PR, which I hear might be "weaponised" for deceptive propaganda
19:10:40 <jeremyrubin> I agree with ML, but also maybe we can add a *temporary editor* if current editors have been too busy in the short term
19:10:51 <luke-jr> would be better to wait until any such concerns are gone
19:11:16 <MarcoFalke> luke-jr: What do you mean with "special treatment"?
19:11:18 <jnewbery> I trust that kallewoof would not give special treatment to any PR. The editor's role is not to show preference/dispreference to PRs.
19:12:12 <wumpus> right the role of BIP editors is to follow the BIP1/2 process, not to pass personal judgement on BIPs besides very basic style criteria
19:12:14 <luke-jr> MarcoFalke: rushed merging outside the usual triage, without full consideration to the factors in concluding it's RTM
19:12:19 <jeremyrubin> What sort of breach of duty under the BIP-0002 defined role would an additional editor make?
19:12:50 <michaelfolkson> It is a tricky situation, the aforementioned PR. I'd like to discuss it and how this type of scenario should be treated in future but better when things have calmed down I think
19:12:55 <jeremyrubin> As far as you've represented previously, you haven't had time to even look at the BIP341 changes which is why it's not merged.
19:13:08 <luke-jr> jeremyrubin: right, maybe it's fine, I don't know
19:13:20 <jnewbery> luke-jr: if you believe that kallewoof is unsuitable and wouldn't fulfil the editor role faithfully, then perhaps you could spell out why you have that concern. It'd save time on the mailing list
19:13:53 <jeremyrubin> +1 jnewbery
19:14:01 <luke-jr> jnewbery: I'm not saying he is unsuitable.
19:14:05 <jeremyrubin> as per BIP-0002, which would need ammending to add kallewoof, BIP authors are responsible for collecting community feedback on both the initial idea and the BIP before submitting it for review. However, wherever possible, long open-ended discussions on public mailing lists should be avoided
19:14:09 <jnewbery> so what's the concern with timing?
19:14:38 <luke-jr> jnewbery: I already summarised.
19:14:42 <jeremyrubin> so if kallewoof is controversial, or an editor, even if better suited to decide on mailing list, we should flesh out what adding an editor means before then
19:14:57 <jeremyrubin> *an addtl editor
19:16:00 <jeremyrubin> I'm also very concerned with "weaponised" for deceptive propagand'
19:16:07 <jnewbery> luke-jr: let me restate your points. Correct me where I go wrong: now is not a good time because a new editor might show preferential treatment to a certain PR. But we don't believe kallewoof would show preferential treatment to PRs. So what's the timing concern
19:16:24 <jeremyrubin> Is this something we need to be preparing for? Like when the copyright claims were made on the whitepaper?
19:17:24 <luke-jr> jnewbery: because the motivation appears to be to get preferential treatment; I have been hit with a lot of nagging, apparently for the purposes of passing off ST as "the" activation method period
19:17:44 <jnewbery> ok, so the concern is not timing, but motivation?
19:17:51 <luke-jr> jnewbery: it would be better to add an editor when there isn't such things going on
19:18:16 <michaelfolkson> Shall we continue on the mailing list as previously suggested?
19:18:19 <wumpus> ok... I don't think this is particularly constructive, let's move it further to the mailing list
19:18:21 <wumpus> yes
19:18:32 <jeremyrubin> noting that it's against BIP-0002 to proceed on mailing list
19:18:38 <luke-jr> jeremyrubin: wut?
19:18:51 <jeremyrubin> "long open-ended discussions on public mailing lists should be avoided"
19:19:00 <luke-jr> sigh
19:19:21 <wumpus> they should be avoided in the weekly core IRC meeting too
19:19:23 <jnewbery> I'm happy to draft an email to the mailing list, but I'd like to understand the process. What's the process for adding an editor? How does it get decided?
19:19:58 <ariard> jeremyrubin: on the other point, I don't think bip2 recommend bitcoin-core-dev as a venue, maybe better suitted to #bitcoin or #bitcoin-wizards
19:20:22 <luke-jr> jnewbery: in the past, it's been the existing editor passes it on, but when I intended to do that in 2018 I found people privately didn't like it, so wider involvement might be better
19:20:30 <jeremyrubin> well I think it's sort of a weird bind, as luke-jr is the author of 0002 who has the only right to amend it
19:20:40 <luke-jr> jeremyrubin: BIP 2 doesn't need to be amended for this
19:20:47 <jeremyrubin> and he's also the editor who judge amendement
19:20:56 <jeremyrubin> so I think jnewbery is right to ask what the heck the process is
19:21:29 <jeremyrubin> I would expect https://github.com/bitcoin/bips/blob/master/bip-0002.mediawiki#bip-editors to be updated
19:21:40 <michaelfolkson> jeremyrubin: I agree it is a bind but binds aren't solved best overnight
19:21:42 <luke-jr> IMO what would make sense, is when the timing is reasonable/calm, I can just propose Kalle to the ML and if nobody objects we add him to the README or whatever
19:21:59 <luke-jr> jeremyrubin: ah, forgot about that
19:22:13 <jnewbery> it does seem somewhat of a centralization problem. The BIPs repo is a venue for sharing proposed changes to Bitcoin, and one person decides who can update it, and also decides whether or not they should ever be replaced/supplemented?
19:22:32 <wumpus> yes
19:22:34 <meshcollider> jeremyrubin: I interpret that "long winded discussion" bit to be about the BIPs themselves, not the process of adding an editor
19:22:37 <luke-jr> jnewbery: seems like it would be good to have the editor cycle every year or two
19:22:38 <jeremyrubin> luke-jr: I think that given conflict of interest you should just appoint a disterested editor/owner for BIP-0002
19:22:48 <harding> luke-jr: I don't agree with the timing issues, but until they're resolved to your satisfaction, is there something we can do to provide you with additional availability so that you can review BIP PRs in a timely manner?
19:23:03 <jonatack> meshcollider: same
19:23:40 <jeremyrubin> meshcollider: it's a self-reference bug of how we defined editorship; I agree it should be fixed!
19:23:55 <luke-jr> harding: hmm, I'm not sure. any suggestions?
19:24:27 <jeremyrubin> Is it displacing paid consulting work or something? How long do you estimate editing work would take?
19:24:33 <luke-jr> (I do expect I can get to it before the signalling begins, either way)
19:25:02 <harding> luke-jr: take over some other work of yours?  Help pay for your lawn maintenance person?  Something like that?
19:25:06 <michaelfolkson> I think in summary luke-jr is happy at some point to add an additional editor, appears to be happy with kallewoof if that is the eventual choice but doesn't want it rushed overnight to fix a PR merge issue
19:25:11 <jonatack> luke-jr: naive suggestion, maybe just take a few minutes to review the PR in question and merge it, issue resolved?
19:25:12 <luke-jr> as a reminder, though, BIPs *are* just documentation, so there really shouldn't need to be a rush
19:26:23 <michaelfolkson> I don't this is productive at this point. An email to the mailing list informing the BIP community that an additional editor is sought is probably a good next step
19:26:27 <jeremyrubin> Well it might be helpful for those implementing ST compatibility for the reference doc for activation to be the latest draft
19:26:38 <jnewbery> I think that for a project that strives for decentralization, a situation where one person has a role and gets to decide whether they should ever be replaced is completely unsuitable
19:26:45 <jeremyrubin> AJ's PR does not move 341 to final IIRC (altho perhaps it should be Active)
19:27:19 <michaelfolkson> jnewbery: luke-jr is saying he is happy to add an additional editor (just not in a rushed manner)
19:27:26 <luke-jr> harding: right now, I'm churning through dealing with the rebase of BIP8 on top of the ST stuff. I suppose that might go faster if there were people willing to review it. But frankly then it almost sounds like I'm holding the BIPs hostage, and I don't want to do that either.
19:27:30 <yanmaani> jnewbery: Do the BIP editors have any actual power?
19:28:07 <yanmaani> I mean, if they'd start to NACK things in bad faith, you could just figure something out if that happens. It doesn't seem like a catastrophic issue.
19:28:16 <jnewbery> yanmaani: in theory, no. But if a BIP editor were acting unfaithfully they could do something like hold up the merge of a PR that the authors had all ACKed
19:28:23 <ariard> quis custodiet ipsos custodes?
19:28:24 <jeremyrubin> What if we just Cordon off the section of the AJ's PR and add a patch that says *activation logic pending further bip editing review, but merged in public information interest*
19:29:31 <michaelfolkson> There are no other topics right? This doesn't seem to be going anywhere
19:29:39 <wumpus> there is another topic
19:29:49 <jnewbery> wumpus: I don't think this one is done
19:30:00 <jnewbery> I'm still not clear on what the process is for adding a new BIP editor
19:30:05 <jeremyrubin> This might be an uncomfortable conversation but I think it's important
19:30:13 <jnewbery> jeremyrubin: +1
19:30:54 <luke-jr> jnewbery: kallewoof was also AIUI planning to write a new BIP to replace BIP 2. maybe this is another topic to resolve in it.
19:31:09 <jnewbery> if the answer is "a new BIP editor is added when and only when luke-jr wants to", then I think we need to change that
19:31:12 <luke-jr> I don't think the current situation is well-defined
19:31:17 <MarcoFalke> luke-jr: The only factor to consider merging a change is whether the bip author(s) are ok with a change
19:31:20 <jeremyrubin> I think the main thing is that it seems like procedure stalling over AJ's PR
19:31:30 <MarcoFalke> (well apart from formatting and technical feasibility, ....)
19:31:35 <jeremyrubin> I think we *should* fix the process. We should also merge AJ's PR.
19:31:42 <jeremyrubin> We don't need to depend one on the other
19:31:50 <luke-jr> jeremyrubin: BIPs PRs merging slowly is not a new thing at all.
19:32:19 <jeremyrubin> What, if anything, do you need to check in the PR and how long would it take you?
19:32:33 <murch> I mean, signaling begins this week and it's not documented in a BIP yet.
19:32:37 <wumpus> yea if the PR is ready for merge it should be merged, in the time of this discussion it could have been merged like 5 times
19:32:42 <jeremyrubin> Like IMO it seems like less time than this meeting is taken?
19:32:44 <jeremyrubin> wumpus: +1
19:33:18 <glozow> I don't understand why the process for adding a new editor would be different based on timing or what PRs are open on the repo
19:33:55 <jnewbery> I also don't understand that. The two things can be handled separately.
19:34:03 <luke-jr> murch: signalling does not begin this week
19:34:17 <michaelfolkson> Someone should propose a process for formalizing the adding a new BIP editor to the mailing list
19:34:18 <murch> starttime = 2021-04-24 00:00 UTC
19:34:23 <wumpus> people really want to see it merged, no one disagrees strongly, why not just cooporate luke-jr, i don't really see why we need to escalate this to add a new editor right now
19:34:29 <meshcollider> BIP PRs merging being merged historically is not a reason to continue being slow forever
19:34:39 <jonatack> wumpus: same. I don't understand what's to be gained here.
19:34:41 <meshcollider> Being merged slowly*
19:35:00 <jnewbery> BIP PRs being merged slowly historically is more evidence that we need to spread the load of BIP repo maintainership
19:35:07 <luke-jr> wumpus: I have the impression people who really want to see it merged, are for deceptive purposes, and that there is ongoing arguments over it on the PR
19:35:23 <luke-jr> wumpus: maybe it is RTM, but I don't expect it's 5 minutes to figure out
19:35:27 <jeremyrubin> also being merged slowly for random things is different than being merged slowly *after being asked for accelerated process*
19:35:35 <michaelfolkson> glozow: luke-jr is of the view that this is only being requested at this time because of a specific PR merge decision. And it does seem that way
19:35:39 <achow101> luke-jr: it has ACKs from all 3 BIP authors, is that not sufficient?
19:35:39 <jnewbery> luke-jr: it doesn't matter whether there are 'ongoing arguments'. The three authors have all ACKed it
19:35:39 <luke-jr> murch: it's the first diff adjustment after that date
19:35:40 <jeremyrubin> harding asked you days ago to do it prior to this optech
19:35:52 <wumpus> separately from that we probably need a new BIP editor, and a process for that, but rushing into that after years of no one showing a single interest in being BIP editor is also a bit strange
19:35:53 <harding> luke-jr: I can link you directly to each of the authors ACKs.
19:36:09 <jnewbery> wumpus: kallewoof has shown interest in helping
19:36:11 <luke-jr> jnewbery: maybe so. I haven't looked.
19:36:30 <jnewbery> luke-jr: very good. Maybe having an extra editor would help
19:36:30 <jeremyrubin> wumpus: I've seen others express interest, but lack of clarity around process and not wanting to insult the current editor
19:36:50 <luke-jr> jnewbery: again, I agree. we should add an editor. I just don't think doing so for this specifically is good timing.
19:37:09 <jnewbery> I'm not suggesting we do it for this specifically
19:37:22 <michaelfolkson> jeremyrubin: If there are other possible candidates other than kallewoof it needs a process
19:37:34 <meshcollider> luke-jr: in the meantime it seems very trivial to go and check the ACKs and then merge it then before proposing the new editor, which would solve the controversial timing issue
19:37:53 <jeremyrubin> michaelfolkson: are there other candidates?
19:37:55 <wumpus> meshcollider: right
19:38:05 <jeremyrubin> ANd I agree it can be discussed on the mailing list
19:38:11 <jnewbery> I'm still curious what the process is for adding a new BIP editor
19:38:12 <jeremyrubin> but jnewbery asked a simple question, what's the process
19:38:13 <michaelfolkson> jeremyrubin: "I've seen others express interest,"
19:38:18 <murch> So, I see two conflicting statements: you haven't checked whether all three bip authors have acked it, and that would be sufficient, but it would take you more than 5 minutes to figure out. How about you check now. We have a minute.
19:38:37 <jeremyrubin> and luke answered in essence when I say so
19:38:42 <luke-jr> meshcollider: but with people trying to politicise it, passing it off as "the activation method" and such, I need to evaluate if the BIP process has any rules/precedent dealing with such things
19:38:42 <jeremyrubin> which isn't really a process
19:39:07 <jeremyrubin> I don't think that we need one or two editors, anyone who wants to and is qualified can be added with reasonable support
19:39:20 <michaelfolkson> jnewbery: The process has not been formalized. If you could draft up a formalized process for the mailing list that would be a productive step
19:39:21 <luke-jr> meshcollider: (I don't think it does, but I'm not certain.)
19:39:23 <jeremyrubin> I think 3-5 editors is probably a good amount, odd # preferred
19:39:49 <michaelfolkson> Next topic....?
19:39:50 <ariard> i think the best answer we have is we don't have a process to add a new bip editor for now and it's a wider community concern than scope of core dev meeting, so better mailing list
19:40:21 <jeremyrubin> luke-jr: if you think the optics of adding an editor now are bad, recognize your role in creating the neccessity of it
19:40:35 <wumpus> clearly there is no process for it at the moment
19:40:44 <luke-jr> jeremyrubin: that's nonsense.
19:40:54 <wumpus> like jeremyrubin says we could just add one if there is sufficient support for it
19:41:00 <glozow> so we are in agreement that jnewbery should draft a proposal for the process and send it to the mailing list?
19:41:04 <wumpus> then agin I'd prefer if luke-jr  agreed
19:41:07 <luke-jr> glozow: sounds good to me
19:41:11 <jeremyrubin> I think that -- by your own admission -- you've said there is an appearance that you're holding the BIP hostage
19:41:31 <luke-jr> if jnewbery is okay with that
19:41:35 <jnewbery> wumpus: there is certainly sufficient support for it
19:41:43 <luke-jr> jeremyrubin: stop twisting my words
19:41:45 <jeremyrubin> That appearance serves to delegitimize the BIP process itself, which is also bad... remove yourself from the situation, just appoint a temporary editor for this BIP
19:41:59 <jeremyrubin> and then let jnewbery take his time to propose a new process
19:42:11 <jeremyrubin> this seems to be a natural compromise
19:42:13 <wumpus> jnewbery: that was fairly clear
19:42:30 <wumpus> jnewbery: I think you can just propose adding kallewoof as BIP editor on the mailing list and see what the response is
19:42:41 <jeremyrubin> wumpus: works for me
19:43:04 <jnewbery> wumpus: who is able to add an editor?
19:43:18 <meshcollider> Any admin of the Bitcoin org
19:43:23 <wumpus> if you mean as to github permissions: any admin of the github org
19:43:25 <wumpus> yes
19:43:40 <jeremyrubin> so you or sipa?
19:44:08 <jnewbery> So what would an admin need in order to be satisfied that such support existed?
19:44:19 <jnewbery> And therefore add a new editor
19:44:24 <michaelfolkson> Is this PR an emergency? Because I am not aware it is...
19:44:53 <wumpus> i would prefer if luke-jr agreed to it
19:45:26 <jeremyrubin> wumpus: by what process would you ignore your preference? it seems unlikely luke-jr would agree
19:45:34 <luke-jr> jeremyrubin: quit trolling
19:45:35 <wumpus> but also agree that this is very centralized right now and if he seems to be blocking things, that is not good optics and such either
19:46:00 <luke-jr> wumpus: I'm not blocking anything. Just doing the same as I have for every other PR for years.
19:46:10 <jeremyrubin> luke-jr: I don't think it's appropriate for you, the bip editor, to call trying to understand how you've ensconced yourself as editor, trolling.
19:46:19 <jnewbery> it's not that it's bad optics. It's bad process for the project. And it's a waste of everyone's time
19:46:34 <michaelfolkson> Is this an emergency PR? If it is I agree it needs emergency measures. If it isn't I think this is a waste of time for all of us
19:46:52 <ariard> imo it's not a good precedent to have admin of the github org substituting to the lack of bip editor appointment process
19:47:00 <jeremyrubin> michaelfolkson: it's not a waste of time as this conversation does have to happen now or in the future
19:47:03 <jnewbery> ariard: there is no process
19:47:14 <jeremyrubin> michaelfolkson: and that is true absent the current PR in question
19:47:21 <luke-jr> there are several outstanding issues with BIP 2 that should be revised. I think we identified one more. seems like the action path is best to work on a new BIP to replace BIP 2.
19:47:25 <michaelfolkson> jeremyrubin: It would be easier to have this conversation without this cloud though
19:47:38 <wumpus> ariard: agree
19:47:48 <jeremyrubin> michaelfolkson: I disagree -- then it would be "we have other more pressing things, why have this stupid debate now"
19:47:51 <ariard> jnewbery: we agree on the lack of process, i'm marking my disagreement on fallbacking to github org admins
19:47:55 <luke-jr> ariard: there is precedent for BIP editor to add BIP editors; so no problem assuming we wait for reasonable timing
19:48:09 <wumpus> ariard: then again i'm just trying to do what people in the project want
19:48:10 <jnewbery> luke-jr: that in itself is a problem
19:48:13 <jeremyrubin> michaelfolkson: there's no good time, place, etc for this convo because it's fundamental stupid procedure issues
19:48:20 <wumpus> ariard: if everyone wants kallewoof as BIP editor i'm going to add him
19:48:27 <jnewbery> wumpus: +1
19:48:29 <jeremyrubin> michaelfolkson: but it's still necessary
19:48:40 <harding> +1 kallewoof as BIP editor
19:48:46 <jeremyrubin> +1 kallewoof
19:49:09 <ariard> wumpus: yes but i think the discussion belongs wider than a core dev meeting, and we should seek consensus on the mailing list
19:49:12 <wumpus> i do prefer it to be proposed on the ML as well
19:49:13 <jeremyrubin> (I'm also +1 to ~anyone else who cares to be editor)
19:49:21 <luke-jr> jeremyrubin: a good time is when it's not being used as a tool toward some other purpose
19:49:24 <michaelfolkson> Not knowing the other candidates I wouldn't oppose kallewoof. I don't like it being rushed because of a PR though
19:49:33 <jeremyrubin> we can seek some rough consensus here tho; to make sure it's not wasting mailing list time
19:49:44 <meshcollider> +1 kallewoof with a ML proposal too
19:49:44 <wumpus> jeremyrubin: i think we have consensus here now
19:49:47 <jeremyrubin> if kallewoof is fundamentally objectionable someone should say so
19:49:57 <wumpus> jeremyrubin: no one here is disagreeing on it, just about timing
19:50:14 <jeremyrubin> this reminds me of soft forks and signalling vs not signalling...
19:50:24 <jeremyrubin> there's value in "people said ok" v.s. "no one disagreed"
19:50:25 <jnewbery> wumpus: very happy to send a post to the mailing list asking for anyone to step forward with objections. If no-one has a reasonable objection within a week or so, then perhaps we should go ahead and do it
19:50:27 <ariard> jeremyrubin: right that's a first step but you have a lot of others community dev involved in the bip process than only core
19:50:31 <jnewbery> I think that's a fair process
19:50:35 <wumpus> jnewbery:sgtm
19:50:46 <jeremyrubin> ariard: yep, I'm not nacking going to mailing list
19:51:02 <wumpus> ok, we have another topic ,so let's move on for now
19:51:04 <meshcollider> luke-jr: as we said, if it's just that PR merge you're worried about for propoganda sake, please go and review it now before kalle is added, then there is no problem
19:51:17 <luke-jr> meshcollider: yes, I probably will get a chance within that week timeframe
19:51:19 <wumpus> #topic 0.20.2 (MarcoFalke)
19:51:20 <core-meetingbot> topic: 0.20.2 (MarcoFalke)
19:51:39 <MarcoFalke> Any objections to release 0.20.2 a week or two after 0.21.1?
19:51:42 <luke-jr> 0.20 doesn't have Taproot logic, right?
19:51:48 <MarcoFalke> luke-jr: no taproot
19:51:53 <MarcoFalke> luke-jr: But bech32m
19:51:59 <wumpus> what is the motivation ? ah right, makes sense then
19:52:00 <luke-jr> at the very least that should be made very clear in the rel notes
19:52:20 <MarcoFalke> Pretty sure sipa added release notes
19:52:34 <jnewbery> MarcoFalke: will there be a taproot v0.20 release shortly after?
19:52:43 <MarcoFalke> jnewbery: No, why?
19:53:11 <luke-jr> jnewbery: IIRC adding Taproot to 0.20 was a can of worms
19:53:27 <jeremyrubin> i think if anyones not following the motivation is "I want to send to addresses people give me, but I run 0.20"
19:53:45 <jnewbery> ah ok then. Never mind
19:54:05 <jeremyrubin> TBH I'm skeptical of value -- are bech32m addresses expected to be used before 0.20 falls out of service?
19:54:08 <luke-jr> besides, it won't activate before November
19:54:23 <MarcoFalke> At this point it might be questionable if anyone upgrades to 0.20.2 even, but we have everything prepared for the release
19:54:30 <jeremyrubin> (and does a point release extend that deadline?)
19:54:42 <luke-jr> MarcoFalke: well, could do a rc1 and leave it at that if there's no feedback
19:54:48 <jeremyrubin> if the question for the topic is just [4/22/21 12:51] <MarcoFalke> Any objections to release 0.20.2 a week or two after 0.21.1?
19:54:53 <jeremyrubin> then i have no objection :)
19:54:55 <murch> jeremyrubin: I think the bigger issue would be that 0.20.1 recognizes native segwit v1 addresses encoded as Bech32 as correct?
19:55:19 <MarcoFalke> murch: It does
19:55:35 <MarcoFalke> murch: Though, there should be no wallet that produces v1 addresses
19:56:40 <murch> Well, some wallets implemented experimental Taproot support before BIP350
19:56:56 <luke-jr> but it can't be used before activation..
19:57:49 <jeremyrubin> I think the benefits of releasing it as a compiled binary that a used can discover are relatively slim... that it has been backported at all is OK
19:58:09 <jeremyrubin> MarcoFalke: I think whatever you decide is OK with me
19:58:37 <MarcoFalke> It would be good to have some kind of process for this
19:58:51 <wumpus> there's not much overhead to doing a release so if someone wants a release we can do it
19:58:59 <MarcoFalke> If the process is "just do an rc1", that's fine
19:59:36 <luke-jr> rc1->final is where things are fuzzy; it makes sense to just not go final in some cases
19:59:53 <luke-jr> if people want a final, they can test rc1 and report back
20:00:02 <wumpus> yes
20:00:13 <luke-jr> if not, it stays at rc1 - that's fine too
20:00:22 <luke-jr> IMO
20:00:43 <wumpus> sgtm, at least the backport has a tag then
20:00:50 <MarcoFalke> ok
20:00:52 <wumpus> so it doesn't get dropped when the branch goes away
20:01:05 <MarcoFalke> bedtime?
20:01:07 <wumpus> (which isn't any time soon but still)
20:01:13 <wumpus> yes, time to conclude the meeting
20:01:18 <wumpus> #endmeeting