19:00:16 <achow101> #startmeeting 
19:00:16 <core-meetingbot> Meeting started Thu May  4 19:00:16 2023 UTC.  The chair is achow101. Information about MeetBot at https://bitcoin.jonasschnelli.ch/ircmeetings.
19:00:17 <core-meetingbot> Available commands: action commands idea info link nick
19:00:22 <hebasto> hi
19:00:25 <achow101> #bitcoin -core-dev Meeting: achow101 _aj_ amiti ariard aureleoules b10c BlueMatt brunoerg cfields darosior dergoegge dongcarl fanquake fjahr furszy gleb glozow hebasto instagibbs jamesob jarolrod jonatack josibake kallewoof kanzure kouloumos kvaciral laanwj LarryRuane lightlike luke-jr MacroFake Murch phantomcircuit pinheadmz promag provoostenator ryanofsky sdaftuar S3RK stickies-v sipa theStack vasild
19:00:31 <josie> hi
19:00:32 <dergoegge> hi
19:00:32 <theStack> hi
19:00:33 <instagibbs> hi
19:00:35 <willcl_ark> hi
19:00:38 <cfields> hi
19:00:39 <achow101> Welcome to the weekly general IRC meeting
19:00:39 <pinheadmz_> Hi
19:00:48 <b10c> hi
19:00:50 <Murch> Hi
19:00:51 <lightlike> hi
19:00:56 <stickies-v> hi
19:00:57 <achow101> we've got several topics today from CoreDev
19:01:02 <kanzure> hi
19:01:07 <glozow> hi
19:01:11 <furszy> hi
19:01:27 <achow101> #topic Project priorities
19:01:27 <core-meetingbot> topic: Project priorities
19:01:48 <achow101> At CoreDev last week, we discussed as a group that we wanted to try something new with having priority projects for the next release cycle.
19:01:56 <neha> hi
19:01:56 <achow101> Priority meaning that PRs in the priority project will take merging precedence if they are (close to being) ready for merge but conflict with another PR that is not part of a priority project.
19:02:09 <achow101> The priority projects will also become permanent topics in the IRC meetings until the next release (or are completed) so that we can get updates on the progress of the topics and figure out what to do next to move them forward.
19:02:23 <achow101> The goal of this is to have things that we can make progress on and have a better idea of the kinds of PRs to actually focus on.
19:03:12 <achow101> Obviously other PRs can still be worked on, and no one is being forced to work on or look at the priority projects
19:03:31 <achow101> and this is just an experiment for the next release, we can change things if it doesn't work out
19:04:13 <achow101> To determine the projects, we discussed having a vote. Many of us voted in person, but we also want the votes of those who weren't able to make it
19:04:27 <achow101> The projects are: Multiprocess, Erlay, BIP 324, Kernel, AssumeUTXO, Legacy Wallet Removal, Package Relay, ASMap, and Silent Payments.
19:04:36 <josie> is there a place to track what the priority projects are? or are we reusing the "high priority for review"
19:04:43 <achow101> are there any others that we may want to add to that list?
19:05:01 <achow101> josie: I think reusing that board is a good idea
19:05:03 <glozow> I think we can add a new column to the high priority for review board for "prioritized projects" or something
19:05:07 <jonatack> hi
19:05:14 <achow101> and also pin the tracking issues/prs for those projects
19:05:22 <glozow> And keep the bug fixes etc, as we will obviously want to get those merged as well
19:05:26 <instagibbs> Ideally I'd like an issue per project, ala https://github.com/bitcoin/bitcoin/issues/27463
19:05:41 <josie> yeah, by tracking im less worried about "what" the projects are and more concerned about tracking the associated PR(s)
19:05:57 <achow101> for the voting, please post your votes for 3 projects that you would like as priorities. we'll count them up and announce before the end of the meeting
19:06:09 <achow101> (obviously don't vote if you voted at coedev, we'll include those counts too)
19:06:22 <kanzure> not to nitpick but i'd like to call it a poll more than a vote *shrug*
19:06:23 <willcl_ark> We could also use temporary repo labels if that would help, but I think a tracking issue would probably be cleaner...
19:06:48 <josie> instagibbs: +1, having an issue to track PRs and discussion is nice. we could add the issues to the high priority for review board
19:07:13 <brunoerg> instagibbs: +1
19:07:20 <instagibbs> e.g., https://bip324.com/sections/code-review/ is stale, would be better imo to just have a tracking issue like package relay
19:07:52 <jonatack> "take merging precedence if they are (close to being) ready for merge but conflict with another PR" -> I thought this was informally the current practice
19:08:24 <fjahr> issues can go stale too but I agree it's a good idea
19:08:40 <achow101> instagibbs: yeah, we should followup with the project authors to get a tracking issue
19:08:54 <instagibbs> fjahr I think the expectation is that is kept fresh on a weekly basis for meetings, if it's a priority project?
19:09:14 <achow101> fjahr: we'll followup each week, so hopefully they don't go stale
19:09:16 <fanquake> That + it's easy for someone else to update a stale issue if need be
19:09:27 <glozow> instagibbs +1, that's how I'm using 27463. I've edited the issue a bunch of times
19:10:05 <glozow> jonatack: yes, but the point here is to get a sense of which projects to prioritize
19:10:13 <josie> fjahr: perhaps the unspoken assumption is that a priority project has a champion(s). if those individuals are not updating the issues and PRs, I assume it would eventually be removed from the priority list
19:10:19 <fanquake> If they do go stale, I'd assume they are no-longer a priotity. None of this works if the person "leading" the project isn't actively involved
19:10:36 <fjahr> Ok, that does make sense, if that is being done it's good. I had issue keeping the tracking issue for coinstatsindex up to date but if there are enough eyes on it it solve that problem
19:10:50 <glozow> if I'm merging I feel more comfortable prioritizing something that the group has said they want to prioritize
19:10:53 <lightlike> i think that in any case it will be more important for the success of this new approach to get a better concentration of review on these projects (rather than merge priority).
19:11:13 <josie> lightlike: +1
19:11:27 <instagibbs> lightlike it's both pieces
19:12:25 <glozow> Hopefully talking about the projects weekly will help keep momentum going!
19:14:53 <achow101> if you haven't voted yet and would like to, please do so at some point during the meeting
19:15:07 <achow101> #topic add ryanofsky as maintainer
19:15:08 <core-meetingbot> topic: add ryanofsky as maintainer
19:15:09 <_aj_> it might make sense for each priority project to have a single "priority pr" that's actively being reviewed for merge real soon at any one time; then anything that conflicts with that PR can be considered blocked, but things that conflict with other PRs in the priority project can still go ahead
19:15:52 <Murch> I had interpreted the voting at Core Dev to be just exploratory and that the actual poll would be conducted out of band when the entire set of contributors could participate during or after meeting. TBH, it feels a bit unfair to make people that were not able to attend to vote here now in public
19:16:07 <fjahr> achow: I guess people can vote with a dm to you if they don't want to vote in public, right?
19:16:14 <josie> _aj_: it would be really nice if the issue tracked the current state of the project, i.e which PR is currently needing review
19:16:23 <achow101> fjahr: sure, or glozow
19:16:41 <Murch> fjahr: good idea
19:16:51 <jon_atack> "which projects to prioritize" -> fwiw I just use the high-prio board for this, coupled with a general idea of the larger projects
19:17:58 <achow101> We (the maintainers) felt that there was a need for a maintainer who understood our interfaces and modularization efforts well, and we think that ryanofsky is a good fit for that.
19:18:46 <fanquake> The high-prio board has clearly been a failure to (really) prioritize anything substantial. The project also needs a bit more direction than "everyone just toss up what they want reviewed at the moment"
19:19:53 <fjahr> Murch: +1 on the vote being pretty short notice. Maybe extend the voting period until the next meeting.
19:20:25 <glozow> I think the biggest problem with high-prio board is that we as a group don't collectively decide what goes on it. It's not a reflection of what "we" think is high priority.
19:20:34 <_aj_> it'd be nice to start prioritising projects and reviewing and merging them, rather than be bogged down in process for it for weeks...
19:20:47 <josie> _aj_: +1
19:20:52 <achow101> _aj_: agreed
19:20:53 <instagibbs> I have a feeling there are already 3/4 clear winners from last week
19:21:13 <glozow> Should we move on to the next topic?
19:21:17 <achow101> I think we can improve the process for next time, and there actually are some very clear winners
19:21:17 <fanquake> aussume utxo, bip324, kernel, package relay
19:22:00 <fjahr> yes, but we can not prioritize all of them
19:22:10 <Murch> _aj_: +1
19:22:20 <ajonas> when prioritizing projects and the champions fade or aren't moving things forward, what happens?
19:22:23 <achow101> fjahr: the plan was the pick the top 3
19:22:54 <achow101> ajonas: the project stalls until someone else wants to champion it? ideally there are multiple champions per project, but ultimately each pr only has one author
19:22:55 <fanquake> in that case, I think drop kernel from the list. As there is a minimal number of substantial PRs left for stage 1
19:23:12 <fanquake> I think they will be merged in the next week or two (ideally) regardless
19:23:17 <achow101> #topic project priorities (cont'd)
19:23:17 <core-meetingbot> topic: project priorities (cont'd)
19:23:24 <fanquake> and post that we could focus on the remaining 3
19:23:29 <fjahr> I think it would be better if we restrict it to an amount that is realistic to get into a release. So two probably.
19:23:41 <fanquake> with kernel stage 2/exploration still happening in the background
19:24:02 <cfields> Yeah,  it's worth mentioning this was titled "v26 priorities" in-person.
19:24:07 <hebasto> agree with fanquake
19:24:08 <achow101> fjahr: the point isn't to complete them, it's really just to get forward progress and momentum
19:24:14 <instagibbs> fjahr BIP324/package relay aren't going to make it into 26 in entirety... absolutely no way
19:24:24 <_aj_> ajonas: i think for apriority PR, we should expect it to make progress in ~3 weeks, then get either merged or removed as a blocker (and reconsidered if updated in another couple of weeks). if a priority project loses momentum, then it just doesn't have a priority PR for a while and no longer manages to block anything else
19:24:30 <fanquake> assume utxo is also nearly a point of "completion" (possibly) already
19:24:31 <jon_atack> Note that every suggestion to add process over the past years to add process hasn't been terribly successful, i believe...i'm not convinced that adding process is a solution in an ad hoc open source project like this. one that, if anything, ought to become more decentralized. but sure.
19:24:35 <Murch> achow101: I thought the idea was to focus on some things that realistically could be shipped with v26
19:24:54 <cfields> ^^
19:24:55 <instagibbs> fanquake right that one might get close in 26
19:24:57 <brunoerg> I had same thought than Murch
19:25:24 <fjahr> then maybe we should just focus on one, I have seen too many projects fail due to a lack of focus and prioritizing 3 huge things equally isn't focus
19:25:42 <jamesob> really late hi
19:25:46 <jon_atack> yes, assumeutxo seems likely for v26 imho
19:25:54 <_aj_> i think 324 and package relay could reasonably make it into 26 if we don't stall out on review
19:25:57 <jon_atack> as i commented on the current step PR
19:25:58 <fanquake> if that was the assumption, why did we even have a vote
19:25:59 <brunoerg> I thought we would choose a project that is really close to be ready and it's just needing a nudge on review/dev to get ready
19:26:08 <achow101> some things are impossible to do in the next release just due to rollout timing
19:26:08 <fanquake> the only obvious choice would be assumeutxo
19:26:18 <fanquake> obviously we aren't shipping any of the other projects in 26
19:26:19 <stickies-v> i don't think being able to ship in the next release should be a requirement for a project being high prio, although ideally *some* of the high prio projects are shippable
19:26:25 <instagibbs> _aj_ the whole project? the crypto library changes aren't even merged for bip213
19:26:32 <instagibbs> 324*
19:26:44 <instagibbs> we can make huge strides for sure
19:27:09 <josie> at least for starting out, not sure if the exact number matters, but if we make progress on one or more of the projects, then id say the prioritization experiment was a success. we can fiddle with the number and process as we go
19:27:28 <_aj_> instagibbs: yes?
19:27:34 <achow101> we can also aim to ship them, but it's not necessarily failure to not ship
19:27:51 <hebasto> achow101: +1
19:27:54 <achow101> and the priorities aren't supposed to be things that prevent us from shipping a release
19:27:59 <ajonas> if the goal is to get big things in, we need to create an environment where reviewers on focused on those rather than working around the edges. They ship when they ship.
19:28:27 <instagibbs> _aj_ I'd love to be proven wrong ofc
19:28:33 <josie> ajonas: +1
19:28:35 <stickies-v> ajonas: josie +1
19:29:08 <_aj_> instagibbs: for me, the main point is being able to pick a PR that's ready to merge, then work on reviewing and merging it, without that work being interrupted by conflicts that force it to get rebased
19:29:20 <cfields> As I understood it, we were picking projects that we'd prioritize for a release cycle.  For ex, given 2 long-lasting conflicting PR's,  one being a priority and one not, the priority project would get the implied focus and merge when ready,  potentially relegating the other to a later release.  But that doesn't mean that the priority item would be a release blocker.
19:29:38 <achow101> cfields: +1
19:30:19 <_aj_> instagibbs: i don't see why we couldn't be doing that for all four of the projects above for the next ~5 months or whatever, and have 324 and pkg relay provide usable features in 26
19:30:25 <jon_atack> cfields: right. (i reckon that can be resolved on an ad hoc basis when it happens tho)
19:30:27 <glozow> fwiw I split package relay into 3 milestones, and I think each one is a reasonable sprint for a release cycle if reviewers are there. I'll commit to responding to feedback and keeping issues updated as fast as possible ✋
19:30:44 <instagibbs> _aj_ definitely, I just didn't think everything would be deliverable
19:30:49 <instagibbs> sub-deliverables 100%
19:31:17 <achow101> I think we're all relatively on the same page
19:31:17 <_aj_> instagibbs: i'd rather be optimistic than give up in advance *shrug*
19:31:25 <achow101> we've got more topics for today
19:31:42 <achow101> #topic add ryanofsky as maintainer (take 2)
19:31:42 <core-meetingbot> topic: add ryanofsky as maintainer (take 2)
19:31:44 <instagibbs> _aj_ I like the energy
19:31:46 <instagibbs> (sorrY)
19:31:52 <achow101> We (the maintainers) felt that there was a need for a maintainer who understood our interfaces and modularization efforts well, and we think that ryanofsky is a good fit for that.
19:31:54 <Murch> So, it sounds like we more or less have picked the priorities and clarified what the criteria for a priority and the goal of the process are
19:31:55 <jamesob> ACK RUSS
19:31:56 <sdaftuar> ack russ
19:32:02 <Murch> ACK Russ
19:32:04 <jamesob> sdaftuar gets it
19:32:08 <hebasto> ACK on Russel
19:32:09 <josie> ACK russ
19:32:12 <dergoegge> ACK russ
19:32:16 <brunoerg> ACK russ
19:32:18 <theStack> ACK russ
19:32:28 <fjahr> I don't know who russ is but ACK Ryan of Sky
19:32:38 <ryanofsky> ack ryan
19:32:53 <cfields> ACK Russ
19:33:03 <_aj_> ack ryan
19:33:14 <lightlike> ACK russ
19:33:16 <achow101> seems uncontroversial, we'll take it to github as usual
19:33:18 <b10c> ryan ack
19:33:18 <instagibbs> ACK russ
19:33:19 <furszy> ACK ryan
19:33:20 <fanquake> have my ACK russ tshirt on
19:33:23 <glozow> ACK
19:33:29 <jamesob> fanquake: nice
19:33:33 <sipa> ACK russ
19:33:37 <cfields> I can't imagine a less controversial candidate :)
19:33:40 <BlueMatt> ACK russ (but my vote doesn't count)
19:33:58 <josie> BlueMatt: not a vote ;)
19:34:18 <stickies-v> ACK russ
19:34:36 <achow101> #topic Change IRC meeting time (glozow)
19:34:36 <core-meetingbot> topic: Change IRC meeting time (glozow)
19:34:43 <glozow> Our current meeting time was decided in 2015 when the group of contributors was fairly different wrt geographic distribution. Several people have expressed wanting to change the meeting time to better-suit our current set of contributors.
19:34:49 <glozow> Last week I sent out a doodle. You can see the results here: https://doodle.com/meeting/participate/id/ax25vR3d
19:34:59 <jon_atack> I'm not sure what the point of voting on IRC is, as after we saw similar support for Vasil, it became clear that it didn't matter
19:35:14 <glozow> 14-15UTC has the most votes.
19:35:14 <glozow> Therefore I propose we change our weekly meeting time to Thursdays 14UTC, starting next week (May 11).
19:35:14 <jon_atack> and that the real decision was made at a different level
19:35:24 <cfields> jon_atack: is that a nack?
19:35:48 <jon_atack> cfields: ACK russ, but i think the process is problematic
19:35:49 <achow101> jon_atack: it is to get an idea whether to bother opening the github pr in the first place
19:36:09 <jon_atack> russ is an experienced and dedicated reviewer and long-term contributor
19:36:18 <josie> jon_atack: again, just to be clear, not a vote
19:36:20 <achow101> the irc meeting is meant for more discussion, if there is any
19:36:21 <hebasto> ACK on 1400 UTC
19:36:22 <jon_atack> he's clearly passionate about this projet
19:36:26 <cfields> jon_atack: roger, thanks for clarifying :)
19:36:37 <achow101> ACK on 1400 UTC
19:36:40 <stickies-v> ACK 14 UTC
19:36:51 <instagibbs> I didn't vote, I was suppressed!!! (I like the change)
19:36:51 <_aj_> that's -5 hours to the current time, and still not changing for daylight savings, right?
19:36:58 <achow101> _aj_: yes
19:37:12 <theStack> ACK 1400 UTC
19:37:18 <instagibbs> effective next week ?
19:37:22 <achow101> instagibbs: gotta check irc more :) we posted it multiple times
19:37:24 <glozow> Yes, effective next week, on May 11
19:37:28 <jamesob> 1400 UTC works
19:37:28 <fjahr> ACK 14 UTC
19:37:33 <brunoerg> ACK 14 UTC
19:37:36 <_aj_> and 1 hour before the optech review twitter space i think?
19:37:42 <josie> ACK 14 UTC
19:37:49 <dergoegge> ACK 14 UTC
19:37:51 <fanquake> ACK 14 UTC
19:37:54 <instagibbs> achow101 my room temp iq couldnt figure out the poll UX
19:37:57 <fanquake> better than 8:00pm
19:38:08 <b10c> ACK 14 UTC
19:38:18 <b10c> instagibbs: yea the site is terrible UX
19:38:38 <instagibbs> to be clear: ACK 14 UTC
19:38:43 <jon_atack> 14 UTC isn't a time I'll be able to make
19:38:45 <Murch> ACK 14 UTC
19:39:27 <achow101> jon_atack: that is unfortunate, but it seems to be the best time for the most contributors
19:39:31 <fanquake> sounds like rough consensus
19:39:33 <lightlike> 14 utc works for me.
19:39:37 <fanquake> ship it next week
19:40:09 <Murch> _aj_: Good point, it’s actually in parallel to the Optech Recap :(
19:40:48 <josie> Murch: any possibility of moving the optech recap?
19:40:54 <_aj_> Murch: oh, is optech on dst?
19:41:24 <Murch> We switched it from 15 UTC because it was interfering with Lunch :p
19:41:57 <fanquake> not sure your lunch is a higher priority than this meeting tbh
19:42:06 <instagibbs> "you can't skip lunch"
19:42:09 <sdaftuar> i think there might be other days of the week
19:42:25 <fanquake> mate you're making me skip dinner
19:42:27 <cfields> Ok, can everyone agree to take lunch at 14utc,  meeting at 15utc? :P
19:42:33 <ajonas> fanquake: burn +1
19:43:08 <glozow> should we have a poll for a different day of the week?
19:43:23 <dergoegge> no optech should move the day
19:43:27 <achow101> meh
19:43:28 <b10c> sunday?
19:43:31 <Murch> haha, fanquake: Don’t worry, we’re gonna move our thing rather than lobbying for moving the coredev meeting
19:43:34 <sdaftuar> yeah i was talking to murch, sorry :)
19:43:44 <achow101> Murch: phew
19:43:44 <glozow> ah okay
19:43:55 <furszy> we can move lunch to sunday
19:44:01 <instagibbs> you are allowed to bitch about it for 2 episodes
19:44:03 <josie> glozow was already prepping the next doodle for day of week
19:44:06 <glozow> Great. Starting next week (May 11), we'll meet at 14UTC.
19:44:30 <glozow> nah I never want to use doodle again 🙈
19:44:36 <Murch> as if all of you are listening to our Recap live or smth
19:44:40 <achow101> #topic project priorities (what they actually are)
19:44:40 <core-meetingbot> topic: project priorities (what they actually are)
19:44:42 <Murch> shakes his head
19:44:56 <glozow> I have not received any DMs
19:45:07 <achow101> nor I
19:45:27 <dergoegge> well then just take the poll results from core dev
19:45:34 <achow101> final counts are Multiprocess - 3, Erlay - 3, BIP 324 - 21, Kernel - 12, AssumeUTXO - 11, Legacy Wallet Removal - 6, Package Relay - 19, ASMap - 3, Silent Payments - 5
19:46:03 <achow101> so that would be BIP 324, Package relay, and kernel as our priorities for 26.0?
19:46:34 <sdaftuar> can you remind us of the champions of each project?
19:46:35 <fanquake> I would suggest swapping kernel for assumeutxo. I think kernel stage 1 will complete shortly, and stage 2 wont interfere with other priorities
19:46:38 <glozow> Can we hear from the people who are championing these projects?
19:46:51 <theStack> fanquake: +1
19:47:04 <fanquake> is thecharlatan here?
19:47:09 <jamesob> What I'll say is that assumeutxo is "nice to have" relative to BIP324 and package relay, albeit it's pretty close
19:47:09 <Murch> TheCharlatan: ?
19:47:10 <achow101> BIP 324 is sipa, package relay is glozow, and kernel is TheCharlatan
19:47:14 <_aj_> why not both assumeutxo and kernel?
19:47:21 <instagibbs> jamesob is assumeutxo
19:47:23 <jamesob> (i.e. BIP324 and package relay are more critical IMO)
19:47:26 <TheCharlatan> yes, still need to catch up
19:47:27 <fanquake> _aj_: yea that's what I mean essentiallyu
19:47:33 <achow101> _aj_: that seems possible too
19:47:55 <jamesob> kernel IMO needs some time to bake in terms of itnerface design... that can't be done overnight
19:47:57 <_aj_> if four projects is too many, we'll hopefully realise it at the weekly priority reviews relatively quickly
19:48:00 <jamesob> *interface
19:48:06 <fjahr> Again, three priorities isn't really focus. We will see the same result as with the high priorities board IMO.
19:48:09 <fanquake> Kernel is going to progress in any case, but once the finaly stage 1 prs are done, which they are not many of, it'll be out of the way, and stage 2 is more exploratory/non-conflicting, so can progress, and assumeutxo can be completed
19:48:15 <_aj_> and if a priority project just doesn't have a priority pr for a few weeks, that seems fine?
19:48:28 <instagibbs> fjahr pick the two you like then, if everyone picks two...
19:49:25 <fjahr> instagibbs It's not on me to decide, I am fine with the two that got the most votes
19:50:01 <sdaftuar> i think the main issue is reviewers; knowing that there are a lot of people stating an interest in review is helpful, as is knowing who those people are (so they can be bugged when needed)
19:50:04 <jonatack1> in any case, people doing review is what moves the dial
19:50:15 <achow101> fjahr: I don't think it will be the same as we will be asking for updates each week
19:50:38 <stickies-v> If kernel is gonna be merged in a few weeks then it'll stop being high prio at that point and we can vote on a next high prio, e.g. assumeutxo?
19:50:46 <stickies-v> (phase 1)
19:51:06 <_aj_> it might be worth having 3 or 4 reviewers stick their hands up for each priority project, as well as a champion? (perhaps you can only be a nominated reviewer for one project, even if you're actually review multiple ones)
19:51:08 <sdaftuar> for my part -- i'm happy to review package relay and assumeutxo in the near term.
19:51:32 <sdaftuar> (assuming that others are lined up as well!)
19:51:41 <_aj_> 324+pkgrelay for me
19:51:46 <achow101> someone will need to make a bip324 tracking issue
19:51:47 <TheCharlatan> ACK for swapping as fanquake suggested, there's maybe like 2-3 stage 1 PRs left. 1 to clean the left over gArgs that I should draft on second thought, and by the looks of it 2 for handling shutdown.
19:51:50 <instagibbs> I'll be focusing on BIP324 and package relay. I can champion either in limited ways
19:52:34 <jamesob> I'm going to be looking at 324, as well as staying on top of assumeutxo as best I can. I have little doubt that others are going to want to see more automated testing than I have built for those changes currently.
19:52:38 <stickies-v> Package relay and kernel for me
19:52:40 <lightlike> I'll review the non-crypto content from bip324, plus the p2p content from pkgrelay
19:52:40 <fanquake> instagibbs: i'll get you a participation trophy
19:53:00 <achow101> TheCharlatan: is there a tracking issue for kernel?
19:53:11 <instagibbs> fanquake CoC violation
19:53:19 <TheCharlatan> I'm working on a new one.
19:53:28 <fanquake> Carl had one, but it likely needs some updating. Maybe we can start a-fresh for V2 atleast
19:53:40 <fanquake> TheCharlatan: great
19:53:45 <theStack> i'll focus mainly on bip324 review (mostly non-secp stuff, ofc)
19:54:21 <achow101> added draft items for kernel and 324. will followup later
19:54:36 <jonatack1> kernel and assumeutxo for me, most likely. more generally, i think what makes a difference is incentivizing the importance of reviewers as the key role.
19:54:49 <instagibbs> achow101 you'll make sure someone is making tracking issues for those two projects you're saying?
19:54:55 <achow101> instagibbs: yes
19:54:59 <instagibbs> thanks
19:55:01 <glozow> for package relay. I'm happy to keep the tracking issue updated and give weekly updates at the meetings (now that we have a new meeting time). Sometimes it might take me some time to implement things but I'll be as responsive as possible. please feel free to ping me in this channel. I nominate _aj_, sdaftuar, instagibbs as potential champions if I get hit by a bus. for those of you who said you'll review, I will take liberties in nagging
19:55:01 <glozow> y'all :P
19:56:08 <instagibbs> 4 minutes left
19:56:17 <achow101> Any other topics?
19:56:36 <fanquake> Test the most recent release candidates
19:56:53 <fanquake> bins are available
19:57:00 <Murch> I’m making progress on fuzzing for the qa-assets
19:57:17 <achow101> yeah, 24.1rc2 and 25.0rc1 are both up
19:57:30 <fanquake> We'll cut a 24.1 quite soon, if no issues come up
19:57:33 <Murch> Oh, should I also fuzz for 24.1?
19:57:45 <achow101> #endmeeting