montxero has quit [Remote host closed the connection]
AaronvanW has joined #bitcoin-core-dev
brunoerg has joined #bitcoin-core-dev
brunoerg has quit [Ping timeout: 268 seconds]
AaronvanW has quit [Ping timeout: 268 seconds]
brunoerg has joined #bitcoin-core-dev
brunoerg has quit [Ping timeout: 250 seconds]
brunoerg has joined #bitcoin-core-dev
brunoerg has quit [Ping timeout: 260 seconds]
cmirror has quit [Remote host closed the connection]
cmirror has joined #bitcoin-core-dev
b_101 has quit [Ping timeout: 240 seconds]
brunoerg has joined #bitcoin-core-dev
brunoerg has quit [Ping timeout: 268 seconds]
cold has quit [Ping timeout: 276 seconds]
cold has joined #bitcoin-core-dev
flooded has quit [Ping timeout: 268 seconds]
b_101 has joined #bitcoin-core-dev
flooded has joined #bitcoin-core-dev
b_101 has quit [Ping timeout: 268 seconds]
brunoerg has joined #bitcoin-core-dev
brunoerg has quit [Ping timeout: 240 seconds]
brunoerg has joined #bitcoin-core-dev
AaronvanW has joined #bitcoin-core-dev
brunoerg has quit [Ping timeout: 246 seconds]
brunoerg has joined #bitcoin-core-dev
brunoerg has quit [Ping timeout: 240 seconds]
AaronvanW has quit [Ping timeout: 268 seconds]
brunoerg has joined #bitcoin-core-dev
brunoerg has quit [Ping timeout: 250 seconds]
brunoerg has joined #bitcoin-core-dev
brunoerg has quit [Ping timeout: 240 seconds]
brunoerg has joined #bitcoin-core-dev
test_ has joined #bitcoin-core-dev
flooded has quit [Ping timeout: 268 seconds]
brunoerg has quit [Ping timeout: 240 seconds]
AaronvanW has joined #bitcoin-core-dev
brunoerg has joined #bitcoin-core-dev
salvatoshi has joined #bitcoin-core-dev
brunoerg has quit [Ping timeout: 260 seconds]
brunoerg has joined #bitcoin-core-dev
aielima has joined #bitcoin-core-dev
brunoerg has quit [Ping timeout: 252 seconds]
b_101 has joined #bitcoin-core-dev
Guyver2 has joined #bitcoin-core-dev
b_101 has quit [Ping timeout: 252 seconds]
b_101 has joined #bitcoin-core-dev
brunoerg has joined #bitcoin-core-dev
aielima has quit [*.net *.split]
bitdex has quit [*.net *.split]
ghost43 has quit [*.net *.split]
qxs has quit [*.net *.split]
pharonix71 has quit [*.net *.split]
SpellChecker_ has quit [*.net *.split]
yanmaani1 has quit [*.net *.split]
b_101 has quit [Ping timeout: 268 seconds]
aielima has joined #bitcoin-core-dev
bitdex has joined #bitcoin-core-dev
yanmaani1 has joined #bitcoin-core-dev
ghost43 has joined #bitcoin-core-dev
qxs has joined #bitcoin-core-dev
pharonix71 has joined #bitcoin-core-dev
SpellChecker_ has joined #bitcoin-core-dev
brunoerg has quit [Ping timeout: 260 seconds]
puchka has quit [Ping timeout: 240 seconds]
brunoerg has joined #bitcoin-core-dev
brunoerg has quit [Ping timeout: 248 seconds]
brunoerg has joined #bitcoin-core-dev
brunoerg has quit [Ping timeout: 260 seconds]
Guyver2 has quit [Quit: Going offline, see ya! (www.adiirc.com)]
brunoerg has joined #bitcoin-core-dev
brunoerg has quit [Ping timeout: 246 seconds]
puchka has joined #bitcoin-core-dev
brunoerg has joined #bitcoin-core-dev
puchka has quit [Ping timeout: 240 seconds]
brunoerg has quit [Ping timeout: 260 seconds]
brunoerg has joined #bitcoin-core-dev
puchka has joined #bitcoin-core-dev
brunoerg has quit [Ping timeout: 248 seconds]
puchka has quit [Ping timeout: 268 seconds]
brunoerg has joined #bitcoin-core-dev
puchka has joined #bitcoin-core-dev
brunoerg has quit [Ping timeout: 246 seconds]
brunoerg has joined #bitcoin-core-dev
brunoerg has quit [Ping timeout: 248 seconds]
brunoerg has joined #bitcoin-core-dev
brunoerg has quit [Ping timeout: 246 seconds]
brunoerg has joined #bitcoin-core-dev
brunoerg has quit [Ping timeout: 250 seconds]
brunoerg has joined #bitcoin-core-dev
brunoerg has quit [Ping timeout: 240 seconds]
<bitcoin-git>
[bitcoin] MarcoFalke opened pull request #27570: refactor: Remove need to pass chainparams from BlockManager methods (master...2305-blockman-chain-params-) https://github.com/bitcoin/bitcoin/pull/27570
Guyver2 has left #bitcoin-core-dev [Closing Window]
brunoerg has joined #bitcoin-core-dev
brunoerg has quit [Ping timeout: 240 seconds]
brunoerg has joined #bitcoin-core-dev
jonatack has quit [Ping timeout: 240 seconds]
jonatack has joined #bitcoin-core-dev
Guest46 has joined #bitcoin-core-dev
<bitcoin-git>
[bitcoin] theStack opened pull request #27572: test: dedup file hashing using `sha256sum_file` helper (master...test-refactor-use_sha256sum_file_helper) https://github.com/bitcoin/bitcoin/pull/27572
bitdex has quit [Ping timeout: 240 seconds]
abubakarsadiq has quit [Read error: Connection reset by peer]
Guest46 has quit [Quit: Client closed]
aielima has quit [Quit: Ciao]
b_101 has joined #bitcoin-core-dev
b_101 has quit [Ping timeout: 240 seconds]
test_ is now known as _flood
abubakarsadiq has joined #bitcoin-core-dev
<bitcoin-git>
[bitcoin] fanquake closed pull request #27364: ci: set docker run --ulimit to workaround Valgrind assertion (master...native_fuzz_valgrind_docker_ulimit) https://github.com/bitcoin/bitcoin/pull/27364
MrFrancis has joined #bitcoin-core-dev
MrFrancis has quit [Client Quit]
<jamesob>
MacroFake: thanks. Eventually was able to repro locally by copying the conf flags exactly from the native_tsan ci/ shell script. Apparently just passing "--with-sanitizers=thread" wasn't sufficient to repro
abubakarsadiq has quit [Ping timeout: 268 seconds]
abubakarsadiq has joined #bitcoin-core-dev
Murch has quit [Quit: Bridge terminating on SIGTERM]
willcl_ark has quit [Quit: Bridge terminating on SIGTERM]
kayabanerve[m] has quit [Quit: Bridge terminating on SIGTERM]
dunxen has quit [Quit: Bridge terminating on SIGTERM]
sequences[m] has quit [Quit: Bridge terminating on SIGTERM]
BlueMatt[m] has quit [Quit: Bridge terminating on SIGTERM]
euclid[m] has quit [Quit: Bridge terminating on SIGTERM]
bohruz[m] has quit [Quit: Bridge terminating on SIGTERM]
Fractal[m]1 has quit [Quit: Bridge terminating on SIGTERM]
provoostenator has quit [Quit: Bridge terminating on SIGTERM]
stratospher[m] has quit [Quit: Bridge terminating on SIGTERM]
sipa has quit [Quit: Bridge terminating on SIGTERM]
denise[m] has quit [Quit: Bridge terminating on SIGTERM]
kakolainen[m] has quit [Quit: Bridge terminating on SIGTERM]
wpaulino has quit [Quit: Bridge terminating on SIGTERM]
bitcoin-git has quit [Quit: Bridge terminating on SIGTERM]
Murch has joined #bitcoin-core-dev
bitcoin-git has joined #bitcoin-core-dev
kakolainen[m] has joined #bitcoin-core-dev
willcl_ark has joined #bitcoin-core-dev
denise[m] has joined #bitcoin-core-dev
sipa has joined #bitcoin-core-dev
stratospher[m] has joined #bitcoin-core-dev
sequences[m] has joined #bitcoin-core-dev
BlueMatt[m] has joined #bitcoin-core-dev
kayabanerve[m] has joined #bitcoin-core-dev
dunxen has joined #bitcoin-core-dev
Fractal[m] has joined #bitcoin-core-dev
euclid[m] has joined #bitcoin-core-dev
provoostenator has joined #bitcoin-core-dev
wpaulino has joined #bitcoin-core-dev
b_101 has joined #bitcoin-core-dev
b_101 has quit [Ping timeout: 260 seconds]
Guest16 has joined #bitcoin-core-dev
Guest16 has quit [Client Quit]
abubakar1adiq has joined #bitcoin-core-dev
abubakarsadiq has quit [Read error: Connection reset by peer]
b_101 has joined #bitcoin-core-dev
bugs_ has joined #bitcoin-core-dev
b_101 has quit [Ping timeout: 264 seconds]
abubakar1adiq has quit [Read error: Connection reset by peer]
<preimage>
I still don't understand why githubstatus has an indicator for githubstatus… is that just so they always get to have one green checkmark showing (or the page doesn't load at all)?
<bitcoin-git>
[bitcoin] MarcoFalke opened pull request #27573: ci: Remove CI_EXEC bloat in test/06_script_b.sh (master...2305-ci-exec-no-) https://github.com/bitcoin/bitcoin/pull/27573
<achow101>
michaelfolkson: we (the maintainers) feel that we need a maintainer that understands our interfaces. We felt that ryanofsky was the obvious choice for this role as he has a lot of experience in that area and is a respected reviewer. This is a different situation from last year as we did not feel the need for another maintainer at that time.
Talkless has joined #bitcoin-core-dev
<jamesob>
incidentally, I'm really happy about ryanofsky being nominated for maintainer. I think he is one of the most experienced, kind devs on the project, and frequently provides detailed review and good feedback for a wide variety of changes. He's one of the only qualified reviewers for coins and other "validation" code.
Guest0 has joined #bitcoin-core-dev
Guest0 has quit [Client Quit]
Guest0 has joined #bitcoin-core-dev
puchka has quit [Ping timeout: 276 seconds]
puchka has joined #bitcoin-core-dev
sr_gi[m] has joined #bitcoin-core-dev
sanket1729_ has left #bitcoin-core-dev [Leaving]
ishaanam[m] has joined #bitcoin-core-dev
sanket1729_ has joined #bitcoin-core-dev
jon_atack has quit [Ping timeout: 248 seconds]
<bitcoin-git>
[bitcoin] dergoegge opened pull request #27574: doc: Add post branch-off note about fuzz input pruning (master...2023-05-release-qa-prune) https://github.com/bitcoin/bitcoin/pull/27574
<sdaftuar>
jamesob: do you have a good workflow for testing assumeutxo? ie if i ran dumptxoutset on an existing node, what's the easiest way to load that in as a snapshot on a fresh node that i want to test?
jon_atack has quit [Quit: WeeChat 3.8]
nintendo1889 has quit [Quit: Connection closed for inactivity]
<achow101>
Welcome to the weekly general IRC meeting
<pinheadmz_>
Hi
<b10c>
hi
<Murch>
Hi
<lightlike>
hi
<stickies-v>
hi
<achow101>
we've got several topics today from CoreDev
<kanzure>
hi
<glozow>
hi
<furszy>
hi
<achow101>
#topic Project priorities
<core-meetingbot>
topic: Project priorities
<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.
<neha>
hi
<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.
<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.
<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.
<achow101>
Obviously other PRs can still be worked on, and no one is being forced to work on or look at the priority projects
<achow101>
and this is just an experiment for the next release, we can change things if it doesn't work out
Eric3 has left #bitcoin-core-dev [#bitcoin-core-dev]
ExEric3 has joined #bitcoin-core-dev
<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
<achow101>
The projects are: Multiprocess, Erlay, BIP 324, Kernel, AssumeUTXO, Legacy Wallet Removal, Package Relay, ASMap, and Silent Payments.
<josie>
is there a place to track what the priority projects are? or are we reusing the "high priority for review"
<achow101>
are there any others that we may want to add to that list?
<achow101>
josie: I think reusing that board is a good idea
<glozow>
I think we can add a new column to the high priority for review board for "prioritized projects" or something
<jonatack>
hi
<achow101>
and also pin the tracking issues/prs for those projects
<glozow>
And keep the bug fixes etc, as we will obviously want to get those merged as well
<josie>
yeah, by tracking im less worried about "what" the projects are and more concerned about tracking the associated PR(s)
brunoerg_ has quit []
<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
brunoerg has joined #bitcoin-core-dev
<achow101>
(obviously don't vote if you voted at coedev, we'll include those counts too)
<kanzure>
not to nitpick but i'd like to call it a poll more than a vote *shrug*
<willcl_ark>
We could also use temporary repo labels if that would help, but I think a tracking issue would probably be cleaner...
<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
<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
<fjahr>
issues can go stale too but I agree it's a good idea
<achow101>
instagibbs: yeah, we should followup with the project authors to get a tracking issue
<instagibbs>
fjahr I think the expectation is that is kept fresh on a weekly basis for meetings, if it's a priority project?
<achow101>
fjahr: we'll followup each week, so hopefully they don't go stale
<fanquake>
That + it's easy for someone else to update a stale issue if need be
<glozow>
instagibbs +1, that's how I'm using 27463. I've edited the issue a bunch of times
<glozow>
jonatack: yes, but the point here is to get a sense of which projects to prioritize
<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
<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
<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
<glozow>
if I'm merging I feel more comfortable prioritizing something that the group has said they want to prioritize
<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).
<josie>
lightlike: +1
<instagibbs>
lightlike it's both pieces
jon_atack has joined #bitcoin-core-dev
jonatack has quit [Read error: Connection reset by peer]
<glozow>
Hopefully talking about the projects weekly will help keep momentum going!
<achow101>
if you haven't voted yet and would like to, please do so at some point during the meeting
<achow101>
#topic add ryanofsky as maintainer
<core-meetingbot>
topic: add ryanofsky as maintainer
<_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
<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
<fjahr>
achow: I guess people can vote with a dm to you if they don't want to vote in public, right?
<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
<achow101>
fjahr: sure, or glozow
<Murch>
fjahr: good idea
<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
<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.
<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"
<fjahr>
Murch: +1 on the vote being pretty short notice. Maybe extend the voting period until the next meeting.
<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.
<_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...
<josie>
_aj_: +1
<achow101>
_aj_: agreed
<instagibbs>
I have a feeling there are already 3/4 clear winners from last week
<glozow>
Should we move on to the next topic?
<achow101>
I think we can improve the process for next time, and there actually are some very clear winners
<fjahr>
yes, but we can not prioritize all of them
<Murch>
_aj_: +1
<ajonas>
when prioritizing projects and the champions fade or aren't moving things forward, what happens?
<achow101>
fjahr: the plan was the pick the top 3
<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
<fanquake>
in that case, I think drop kernel from the list. As there is a minimal number of substantial PRs left for stage 1
<fanquake>
I think they will be merged in the next week or two (ideally) regardless
<fanquake>
and post that we could focus on the remaining 3
<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.
Guest0 has quit [Quit: Client closed]
<fanquake>
with kernel stage 2/exploration still happening in the background
<cfields>
Yeah, it's worth mentioning this was titled "v26 priorities" in-person.
<hebasto>
agree with fanquake
<achow101>
fjahr: the point isn't to complete them, it's really just to get forward progress and momentum
<instagibbs>
fjahr BIP324/package relay aren't going to make it into 26 in entirety... absolutely no way
<_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
<fanquake>
assume utxo is also nearly a point of "completion" (possibly) already
<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.
<Murch>
achow101: I thought the idea was to focus on some things that realistically could be shipped with v26
<cfields>
^^
<instagibbs>
fanquake right that one might get close in 26
<brunoerg>
I had same thought than Murch
<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
<jamesob>
really late hi
<jon_atack>
yes, assumeutxo seems likely for v26 imho
<_aj_>
i think 324 and package relay could reasonably make it into 26 if we don't stall out on review
<jon_atack>
as i commented on the current step PR
<fanquake>
if that was the assumption, why did we even have a vote
<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
<achow101>
some things are impossible to do in the next release just due to rollout timing
<fanquake>
the only obvious choice would be assumeutxo
<fanquake>
obviously we aren't shipping any of the other projects in 26
<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
<instagibbs>
_aj_ the whole project? the crypto library changes aren't even merged for bip213
<instagibbs>
324*
<instagibbs>
we can make huge strides for sure
<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
<_aj_>
instagibbs: yes?
<achow101>
we can also aim to ship them, but it's not necessarily failure to not ship
<hebasto>
achow101: +1
<achow101>
and the priorities aren't supposed to be things that prevent us from shipping a release
<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.
<instagibbs>
_aj_ I'd love to be proven wrong ofc
<josie>
ajonas: +1
<stickies-v>
ajonas: josie +1
<_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
<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.
<achow101>
cfields: +1
<_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
<jon_atack>
cfields: right. (i reckon that can be resolved on an ad hoc basis when it happens tho)
<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 ✋
<instagibbs>
_aj_ definitely, I just didn't think everything would be deliverable
<instagibbs>
sub-deliverables 100%
<achow101>
I think we're all relatively on the same page
<_aj_>
instagibbs: i'd rather be optimistic than give up in advance *shrug*
<achow101>
we've got more topics for today
<achow101>
#topic add ryanofsky as maintainer (take 2)
<core-meetingbot>
topic: add ryanofsky as maintainer (take 2)
<instagibbs>
_aj_ I like the energy
<instagibbs>
(sorrY)
<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.
<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
<jamesob>
ACK RUSS
<sdaftuar>
ack russ
<Murch>
ACK Russ
<jamesob>
sdaftuar gets it
<hebasto>
ACK on Russel
<josie>
ACK russ
<dergoegge>
ACK russ
<brunoerg>
ACK russ
<theStack>
ACK russ
<fjahr>
I don't know who russ is but ACK Ryan of Sky
<ryanofsky>
ack ryan
<cfields>
ACK Russ
<_aj_>
ack ryan
<lightlike>
ACK russ
<achow101>
seems uncontroversial, we'll take it to github as usual
<b10c>
ryan ack
<instagibbs>
ACK russ
<furszy>
ACK ryan
<fanquake>
have my ACK russ tshirt on
<glozow>
ACK
<jamesob>
fanquake: nice
<sipa>
ACK russ
<cfields>
I can't imagine a less controversial candidate :)
<BlueMatt>
ACK russ (but my vote doesn't count)
<josie>
BlueMatt: not a vote ;)
<stickies-v>
ACK russ
<achow101>
#topic Change IRC meeting time (glozow)
<core-meetingbot>
topic: Change IRC meeting time (glozow)
<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.
<achow101>
so that would be BIP 324, Package relay, and kernel as our priorities for 26.0?
<sdaftuar>
can you remind us of the champions of each project?
<fanquake>
I would suggest swapping kernel for assumeutxo. I think kernel stage 1 will complete shortly, and stage 2 wont interfere with other priorities
<glozow>
Can we hear from the people who are championing these projects?
<theStack>
fanquake: +1
<fanquake>
is thecharlatan here?
<jamesob>
What I'll say is that assumeutxo is "nice to have" relative to BIP324 and package relay, albeit it's pretty close
<Murch>
TheCharlatan: ?
<achow101>
BIP 324 is sipa, package relay is glozow, and kernel is TheCharlatan
<_aj_>
why not both assumeutxo and kernel?
jonatack1 has joined #bitcoin-core-dev
<instagibbs>
jamesob is assumeutxo
<jamesob>
(i.e. BIP324 and package relay are more critical IMO)
<TheCharlatan>
yes, still need to catch up
<fanquake>
_aj_: yea that's what I mean essentiallyu
<achow101>
_aj_: that seems possible too
<jamesob>
kernel IMO needs some time to bake in terms of itnerface design... that can't be done overnight
<_aj_>
if four projects is too many, we'll hopefully realise it at the weekly priority reviews relatively quickly
<jamesob>
*interface
<fjahr>
Again, three priorities isn't really focus. We will see the same result as with the high priorities board IMO.
<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
<_aj_>
and if a priority project just doesn't have a priority pr for a few weeks, that seems fine?
<instagibbs>
fjahr pick the two you like then, if everyone picks two...
<fjahr>
instagibbs It's not on me to decide, I am fine with the two that got the most votes
jon_atack has quit [Ping timeout: 260 seconds]
<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)
<jonatack1>
in any case, people doing review is what moves the dial
<achow101>
fjahr: I don't think it will be the same as we will be asking for updates each week
<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?
<stickies-v>
(phase 1)
<_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)
<sdaftuar>
for my part -- i'm happy to review package relay and assumeutxo in the near term.
<sdaftuar>
(assuming that others are lined up as well!)
<_aj_>
324+pkgrelay for me
<achow101>
someone will need to make a bip324 tracking issue
<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.
<instagibbs>
I'll be focusing on BIP324 and package relay. I can champion either in limited ways
<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.
<stickies-v>
Package relay and kernel for me
<lightlike>
I'll review the non-crypto content from bip324, plus the p2p content from pkgrelay
<fanquake>
instagibbs: i'll get you a participation trophy
<achow101>
TheCharlatan: is there a tracking issue for kernel?
<instagibbs>
fanquake CoC violation
<TheCharlatan>
I'm working on a new one.
<fanquake>
Carl had one, but it likely needs some updating. Maybe we can start a-fresh for V2 atleast
<achow101>
added draft items for kernel and 324. will followup later
<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.
<instagibbs>
achow101 you'll make sure someone is making tracking issues for those two projects you're saying?
<achow101>
instagibbs: yes
<instagibbs>
thanks
<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
<glozow>
y'all :P
<instagibbs>
4 minutes left
<achow101>
Any other topics?
<fanquake>
Test the most recent release candidates
<fanquake>
bins are available
<Murch>
I’m making progress on fuzzing for the qa-assets
<achow101>
yeah, 24.1rc2 and 25.0rc1 are both up
<fanquake>
We'll cut a 24.1 quite soon, if no issues come up
<core-meetingbot>
Meeting ended Thu May 4 19:57:45 2023 UTC.
<Murch>
I’ve just been fuzzing for 25.0
<glozow>
Great meeting
<josie>
glozow: make irc lively again
<fanquake>
#productive
<sdaftuar>
jamesob: i managed to load a utxo set (i think). hacked in a new rpc that takes a dumptxoutset from another node. however! it is taking forever to flush the chainstate to disk. is that what you have observed as well or is my computer just bad?
<Murch>
glozow: +1
<jamesob>
sdaftuar: yep, that's the longest part of the load process for sure. How long we talking?
<achow101>
TheCharlatan: what's the next pr for kernel?
<jamesob>
Shouldn't be more than ~10 minutes...
<sdaftuar>
i'm at over 20 already, still going
<jamesob>
zoinks
<jamesob>
spinning disk or ssd?
<sdaftuar>
close to 30 minutes. spinning disk yeah
<sdaftuar>
also maybe my btrfs filesystem is not optimized for this... i think i might have mirroring of data enabled
<jamesob>
for what it's worth I've got a bunch of new changes on #15606 as of the last few days... once CI passes, I'll be posting comprehensive instructions for testing it out
<sdaftuar>
i'm going to try to test some download logic... if this flush every finishes!
<jamesob>
:)
<fanquake>
meeting barely over and there's already assumeutxo progress
<fjahr>
jamesob: turns out assumeutxo is slower than syncing the chain? ;)
<jamesob>
fjahr: don't send me into retirement
<_aj_>
achow101: drop the "needs rebase" ad-hoc entries and pkg relay from chasing concept ack?
<achow101>
_aj_: done
<fjahr>
achow101: did you change your mind about dropping the board? I thought you put that on the agenda as a topic :)
<TheCharlatan>
achow101 next one is getting rid of whatever gArgs are still left over (I'll open it in a bit). Still working on shutdown, so don't know when that will be ready.
<achow101>
fjahr: yeah, I did
<cfields>
TheCharlatan: oh, you decided to tackle shutdown afterall? What approach?
abubakarsadiq has quit [Read error: Connection reset by peer]
<cfields>
Or you mean more like dealing with our current shutdown behavior?
<jonatack1>
jamesob: nice, i'll be looking out for those changes on 15606 and the testing info
<TheCharlatan>
cfields, yeah, the discussion you brought up at last week's meeting made me think it over. Currently I am tending towards a polymorphic solution that either wraps the current behaviour, or provides kernel users with enough context to handle destruction.
kevkevin_ has quit [Remote host closed the connection]
<cfields>
TheCharlatan: ack. I had been thinking it through since the discussion and arrived at throwing and catching at our boundary, then bubbling up to the user from there as an error and letting them handle as you mentioned.
<cfields>
happy to review or work through it with you. It's kept me up plenty of nights :)
<cfields>
Also I have commits which demonstrate the callgraphs if that'd be helpful...
<TheCharlatan>
cfields: yes, it would :)
<cfields>
TheCharlatan: roger. Will generate it for you tomorrow.
<theStack>
sdaftuar: just to understand your assumeutxo test scenario better (as i also plan to play around with it soon), what's the difference between the `loadtxoutset` RPC in #15606 and the one you hacked in?
<sdaftuar>
theStack: oh, thanks for the link! I didn't know where to find james' implementation
<sdaftuar>
i think my implementation is a worse version of jamesob's, but accomplishes the same thing :)
<sdaftuar>
i did have to add the blockhash from my dumptxoutset command (and the block height) to chainparams as a valid assumeutxo value.
jonatack1 has quit [Quit: WeeChat 3.8]
jonatack has joined #bitcoin-core-dev
<bitcoin-git>
[bitcoin] TheCharlatan opened pull request #27576: kernel: Remove args, chainparams, chainparamsbase from kernel library (master...rmKernelArgs) https://github.com/bitcoin/bitcoin/pull/27576
brunoerg has quit [Remote host closed the connection]
brunoerg has joined #bitcoin-core-dev
brunoerg has quit [Ping timeout: 240 seconds]
kevkevin has joined #bitcoin-core-dev
preimage has quit [Quit: WeeChat 3.8]
brunoerg has joined #bitcoin-core-dev
brunoerg has quit [Ping timeout: 240 seconds]
<ariard>
ACK Russ maintainer + ACK 1400 UTC Thurs. new meeting schedule + package relay as my review prio
bitdex has joined #bitcoin-core-dev
<bitcoin-git>
[bitcoin] mzumsande opened pull request #27577: p2p: give seednodes time before falling back to fixed seeds (master...202304_seednode_fixedseed_interaction) https://github.com/bitcoin/bitcoin/pull/27577
brunoerg has joined #bitcoin-core-dev
brunoerg has quit [Ping timeout: 248 seconds]
brunoerg has joined #bitcoin-core-dev
<_aj_>
TheCharlatan: thought you mean remove kernel/chainparams*.cpp from kernel when i saw that title :)
brunoerg has quit [Ping timeout: 260 seconds]
brunoerg has joined #bitcoin-core-dev
aielima has quit [Quit: Ciao]
brunoerg has quit [Ping timeout: 240 seconds]
<glozow>
ariard: 🚀🚀🚀
brunoerg has joined #bitcoin-core-dev
brunoerg has quit [Ping timeout: 265 seconds]
brunoerg has joined #bitcoin-core-dev
kevkevin has quit [Remote host closed the connection]
brunoerg has quit [Ping timeout: 260 seconds]
jonatack has quit [Ping timeout: 265 seconds]
brunoerg has joined #bitcoin-core-dev
<bitcoin-git>
[bitcoin] benthecarman opened pull request #27578: Allow accepting non-standard transactions on mainnet (master...non-std-tx-mainnet) https://github.com/bitcoin/bitcoin/pull/27578
brunoerg has quit [Ping timeout: 268 seconds]
jonatack has joined #bitcoin-core-dev
<theStack>
sdaftuar: nice! that's very instructive for sure. i'm going the way easier testing route, running james' pr (which already has the assumeutxo values filled in for height 788000) and trying to load the snapshot
<theStack>
./contrib/devtools/utxo_snapshot.sh is useful btw for creating a snapshot at height N, only discovered that after doing the rewind manually