<achow101>
Feature freeze is scheduled for this Monday
<achow101>
anything we should add or remove to the milestone?
<fjahr>
I know I’ve been harping on about this for a while but since we are so close, it would be great if we could tag the remaining important Assumeutxo PRs for v28. #29519 already has two ACKs. #28553 would be necessary too and we had intense discussions over the last two days so I hope we can lay this to rest quickly now. Technicallyyyy both of these are fixing bugs in the existing assumeutxo feature (signet/testnet3) so I
<fjahr>
don’t think they would necessarily even need to make it in before feature freeze. And then of course #30598 which technicallyyyy is updating chain params which is also something we usually do after feature freeze :p
<gribble>
https://github.com/bitcoin/bitcoin/issues/29519 | p2p: For assumeutxo, download snapshot chain before background chain by mzumsande · Pull Request #29519 · bitcoin/bitcoin · GitHub
<fjahr>
Most importantly I think a lot of people have been involved in, improved and better understood assumeutxo over the last 6 months (again see #29616) and the vibe I have been getting from others is that there is agreement that the feature is ready for mainnet use, especially since setting an initial height at 840k is really low risk.
<achow101>
sipa: I think it might not make it for feature freeze
<achow101>
maybe for 29.0?
<fjahr>
achow101: yepp, nothing else to add
<sipa>
achow101: agreed
<achow101>
#topic Future of priority projects (achow101)
<achow101>
At the last CoreDev, we had a discussion about priority projects. I recall that the general sentiment was that it was getting less effective since we moved to doing online polling and such.
<achow101>
IIRC we concluded that for the next set of priority projects, we would determine them in person at the October CoreDev
<sipa>
that would be my preference
<fjahr>
I think this is something that is best discussed in an in-person meeting but as an idea: it might be an interesting experiment to see what happens to priority projects if there isn’t one champion but 2-3 instead. If there are not 2-3 people interested in or capable of championing for a project, then maybe it’s not a good fit (yet).
<achow101>
So I think once we past feature freeze on Monday, the current priority projects will be cleared, and we'll not have any until next CoreDev
<sipa>
fjahr: my view is that *any* vote for a priority project should mean "i commit to actively contributing/reviewing PRs related to this feature if it ends up winning"
<glozow>
achow101: that makes sense to me
<fjahr>
sipa: that would be ideal but doesn't seem to be the reality :/
<sipa>
fjahr: that seems to be a communication issue to me
<fjahr>
maybe there should be the option or urge for people to not put in all of their votes if they don't want to do that
bezel_ has joined #bitcoin-core-dev
bezel_ has quit [Client Quit]
<fjahr>
but best discussed in person probably..
<sipa>
fjahr: yeah
<jonatack>
would contributors not attending coredev be asked for input?
<sipa>
i think it makes sense to start proposals/nominations before coredev, and then continue permitting voting by org members after... but the benefit of actually having the fast interactive discussion in person seems evident to me
<fjahr>
I guess these are different side of a spectrum on forming teams around a priority project, which I think would be a good direction for experimenting
<fjahr>
*sides
<lightlike>
i don't think that the voting modus has much to do with the effectiveness. I think if there aren't enough people who would be willing change what they will work on based on the outcome of the vote, the vote doesn't really make a difference.
dzxzg has quit [Ping timeout: 272 seconds]
<achow101>
I think a big component of why it worked the first time was because we did it in person and the vote gave people the motivation to shill their projects and convince others to work on it while we were all in the same place
<jonatack>
it could possibly furthermore be argued that both coredev and additional project management processes can be centralization pressures, to an extent. so while they can be more or less somewhat effective, my preference is more in the direction of ad hoc rather than process
<Murch[m]>
I wouldn’t perceive it as a vote in that sense: it’s more of taking a census of what people intend to work on, and giving projects with a lot of contributors a focus in the meetings.
<fjahr>
lightlike: I think sipa's point is less about the mode of voting but actually buy in from the voters
<achow101>
jonatack: tbh this is pretty ad hoc. we're making up the process as we go :p
<jonatack>
achow101: :)
<furszy>
I think we should just take it as a public way of forming working groups with weekly updates on the most voted ones.
<achow101>
anyways, the point is that we'll try something different for 29.0, and it will likely be centered around discussions that occur at CoreDev
<achow101>
Any other topics?
willcl-ark has quit [Quit: left]
<glozow>
fwiw, I disagree that trying to communicate what our plans are to form working groups is centralization pressure. We can be decentralized without being disorganized.
<jonatack>
achow101: sure. if/when in doubt, suggest less process over more. side benefit: more interesting, less mechanical meetings
<achow101>
#endmeeting
kashifs has quit [Quit: Client closed]
Emc99 has quit [Quit: Client closed]
<achow101>
jonatack: we did that for years before the first batch of priority projects and "more interesting, less mechanical meetings" is categorically untrue
<achow101>
those meetings were boring as hell and very mechanical, with me being the only person talking because I was running them
willcl-ark has joined #bitcoin-core-dev
willcl-ark has joined #bitcoin-core-dev
<jonatack>
achow101: i'm referring to meetings earlier than that. certainly, that's my opinion.
<achow101>
and clearly something stopped working between then and for the few years prior to priority projects. I don't think going back to that is going to help anyone, nor is sticking with what we currently do
<achow101>
changing things up might mean "process", but I think that trying to organize to get stuff done is better than the cycle of stalling that we were stuck in for years
<fjahr>
It's tricky, I would say that assumeutxo was a success as in we got a lot done over the last 6 months without any organizational structure and without it even being a priority project. But I wouldn't say that this is repeatable because there were also years of lingering for that project before that. Ideally things don't take that long to begin with and for that I think amore structure is necessary.
<jonatack>
sure, "change" is fine and the way of things.
<jonatack>
(fine, as in, to be expected)
<ajonas>
The purpose of priority projects is not to tell people what to do, but rather to help contributors collaborate in a more efficient way. The exercise of writing down goals and checking in on them has an effect.
Guyver2 has joined #bitcoin-core-dev
pigeons has joined #bitcoin-core-dev
pigeons has joined #bitcoin-core-dev
bugs_ has joined #bitcoin-core-dev
Guyver2 has left #bitcoin-core-dev [Closing Window]
puchka has joined #bitcoin-core-dev
abubakarsadiq has quit [Quit: Connection closed for inactivity]
preimage has joined #bitcoin-core-dev
TheCharlatan has joined #bitcoin-core-dev
mcey_ has joined #bitcoin-core-dev
Sjors[m]11 has joined #bitcoin-core-dev
uasf has joined #bitcoin-core-dev
mcey has quit [Ping timeout: 260 seconds]
zeropoint has joined #bitcoin-core-dev
Earnestly has quit [Ping timeout: 255 seconds]
jamesob443688173 has joined #bitcoin-core-dev
jamesob15 has joined #bitcoin-core-dev
jonatack has quit [Ping timeout: 255 seconds]
kevkevin has quit [Remote host closed the connection]
dermoth has quit [Read error: Connection reset by peer]
dermoth has joined #bitcoin-core-dev
<sipa>
the line "m_ibd_chainstate->ForceFlushStateToDisk();" in ChainstateManager::MaybeCompleteSnapshotVal
<sipa>
idation
<sipa>
since the flush/sync separation, is it desirable/necessary that this call wipes the cache, or does just writing changes to disk suffice?
andrewtoth has quit [Remote host closed the connection]
andrewtoth has joined #bitcoin-core-dev
kevkevin has joined #bitcoin-core-dev
oneeyedalien has joined #bitcoin-core-dev
<bitcoin-git>
[bitcoin] sipa opened pull request #30610: validation: do not wipe utxo cache for stats/scans/snapshots (master...202408_force_sync) https://github.com/bitcoin/bitcoin/pull/30610
Earnestly has joined #bitcoin-core-dev
oneeyedalien has quit [Ping timeout: 260 seconds]
jonatack has joined #bitcoin-core-dev
pigeons has quit [Ping timeout: 248 seconds]
oneeyedalien has joined #bitcoin-core-dev
<bitcoin-git>
[bitcoin] andrewtoth opened pull request #30611: validation: write chainstate to disk every hour (master...write-chainstate-every-hour) https://github.com/bitcoin/bitcoin/pull/30611
<bitcoin-git>
[bitcoin] andrewtoth closed pull request #15218: validation: sync chainstate to disk after syncing to tip (master...flush-after-ibd) https://github.com/bitcoin/bitcoin/pull/15218