< jonasschnelli>
meshcollider: I think you should add the GUI repository as your push mirror
< jonasschnelli>
meshcollider: just add "githubmerge.pushmirrors=git@github.com:bitcoin-core/gui.git" to your git config (the merge script will pick this up)
< bitcoin-git>
[bitcoin] MarcoFalke opened pull request #21222: log: Clarify log message when file does not exist (master...2102-logFile) https://github.com/bitcoin/bitcoin/pull/21222
< bitcoin-git>
[bitcoin] vasild opened pull request #21223: style: make clang-format break long lines (master...clang-format-ColumnLimit) https://github.com/bitcoin/bitcoin/pull/21223
< bitcoin-git>
bitcoin/master b4511e2 practicalswift: log: Prefix log messages with function name if -logsourcelocations is set
< bitcoin-git>
bitcoin/master b805dbb Wladimir J. van der Laan: Merge #19809: log: Prefix log messages with function name and source code ...
< bitcoin-git>
[bitcoin] laanwj merged pull request #19809: log: Prefix log messages with function name and source code location if -logsourcelocations is set (master...logfunctionnames) https://github.com/bitcoin/bitcoin/pull/19809
< provoostenator>
meshcollider: thanks for the shout out. wumpus: I'm fixing the boost::process rebase glitch now
< bitcoin-git>
[bitcoin] ariard opened pull request #21224: [p2p] Halt processing of unrequested transactions (master...2021-02-halt-processing-unrequested) https://github.com/bitcoin/bitcoin/pull/21224
< bitcoin-git>
[bitcoin] jonatack closed pull request #21181: p2p: if no anchors.dat file, log a message instead of an error (master...log-message-instead-of-error-if-missing-anchors) https://github.com/bitcoin/bitcoin/pull/21181
< fanquake>
meshcollider: please don’t merge yet. I’d like to leave a few comments in regards to #ifdefs.
< bitcoin-git>
[bitcoin] antanst opened pull request #21225: doc: Remove dead whitepaper link from README (master...doc_remove_whitepaper_link) https://github.com/bitcoin/bitcoin/pull/21225
< wumpus>
we've been almost running out of blockers this week :)
< wumpus>
#topic would we merge a proposal from the taproot activation meetings (achow101)
< core-meetingbot>
topic: would we merge a proposal from the taproot activation meetings (achow101)
< achow101>
A question that came up during the taproot activation meetings was whether we would merge whatever activation parameters were decided
< achow101>
notably the question was whether a lockinontimeout=true parameter would be merged
< sdaftuar>
that seems like an odd question -- woulnd't we just follow our usual practice of review and discussion?
< luke-jr>
achow101: also questionable if LOT=false would be merged
< fjahr>
I guess someone can open a PR with the meeting results as an argument and then it goes through review?
< wumpus>
right, simply PR it
< provoostenator>
(hi)
< luke-jr>
sdaftuar: protocol changes are not for developers to decide, only follow; same as with miners
< achow101>
I have no doubt that the code itself would go through the normal review process
< sdaftuar>
luke-jr: no one here is obligated to accept decisions from anyone else
< achow101>
I suppose what I'm asking is more of would developers have opinions about the parameters themself
< achow101>
that would prevent the merging of the params if all the code was fine
< wumpus>
no, i have no opinions about that
< luke-jr>
sdaftuar: to implement a protocol distinct from what the Bitcoin community defines for Bitcoin would constitute ceasing to be a Bitcoin implementation
< provoostenator>
achow101: no floats
< luke-jr>
provoostenator: lol ☺
< bitcoin-git>
[bitcoin] fanquake closed pull request #21225: doc: Remove dead whitepaper link from README (master...doc_remove_whitepaper_link) https://github.com/bitcoin/bitcoin/pull/21225
< michaelfolkson>
I'd like to make clear that multiple Bitcoin Core contributors effectively NACKed lot=true in the meeting and as far as I could make out only one Bitcoin Core contributor effectively NACKed lot=false
< sdaftuar>
luke-jr: PRs that have consensus get merged. i don't understand what we are discussing -- proposing that we merge something that doens't have consensus?
< meshcollider>
I don't think there's any world in which this won't be a controversial PR somehow
< luke-jr>
sdaftuar: Segwit did not have consensus.
< provoostenator>
(off topic: feature_blockfilterindex_prune.py is consistently failing on master for macOS CI)
< sipa>
just open a PR, details can be discussed there
< MarcoFalke>
provoostenator: File an issue? ;)
< provoostenator>
So much for "once we get rid of Travis, paradise"
< provoostenator>
Doing so
< luke-jr>
O.O
< jonasschnelli>
hi
< MarcoFalke>
provoostenator: Bugs in our tests can't be fixed by the platform the run on
< MarcoFalke>
*they
< jeremyrubin>
things like "timeout lack of output" can be tho tbf
< jeremyrubin>
but I guess it's semantic on what you consider the bug in the test
< luke-jr>
all we can do is fix it and prioritise review of the fix
< achow101>
sdaftuar: my question is to inform whether, during the taproot activation meetings, we should be considering whether the activation parameters that get decided on would not be merged due to opinions of those parameters by developers who were not present in those meetings
< sdaftuar>
achow101: i would think that the whole community's views should be considered, including those of people not present
< michaelfolkson>
The advice given (I think by achow101) was that if Core contributors had strong views either way they would have attended the meeting. I don't think this is necessarily the case if they didn't think it was a productive use of time
< achow101>
i agree they should be considered, but I don't think that they should be only considered at the time a pr is proposed
< luke-jr>
sdaftuar: but refusing to speak up publicly, either there or here, makes that impractical ;)
< jeremyrubin>
as someone who was not present, but has a view, I felt that I've made my views relatibvely clear beforehand and did not need to attend a meeting
< achow101>
and such an opinion could nack that pr and cause it to not be merged
< luke-jr>
jeremyrubin: I have no idea what your views are fwiw
< michaelfolkson>
Tbf I haven't heard your view either on LOT jeremyrubin
< jeremyrubin>
Ok
< luke-jr>
and I doubt most at the meetings did
< jeremyrubin>
I'm just lending credence to the notion that non participation at the meeting != would have attended meeting
< michaelfolkson>
Basically strong views exist but they weren't present to voice them at the meeting (I'm hearing)
< michaelfolkson>
Which is fine, that is what I assumed
< luke-jr>
(otoh even among the ~100 who did go to the meeting, consensus seems impractical, so I'm not sure adding more people to the mix is going to help anything at this point)
< achow101>
What I want to avoid is having activation parameters be proposed in a pr that gets shot down by someone with strong opinions who didn't participate in various discussions about those parameters
< michaelfolkson>
Again, I can only voice my personal opinion from what I've heard so far which is if LOT is going to be set in Core the only viable option at this stage is false (based on effective NACKs)
< wumpus>
i don't think you can avoid that in practice, if you open a PR there's going to be discussion there
< wumpus>
no one can pre-bless anything
< jeremyrubin>
I think that if something is to be read as nacked, a PR should just be opened for it so people can leave a formal comment
< provoostenator>
I think IRC meetings are good for brainstorming and maybe exchanging some ideas, but mailinglist seems more appropriate
< michaelfolkson>
provoostenator: Agreed, strong views welcome on the mailing list
< sdaftuar>
achow101: i think if a proposal really has consensus this should not be a big concern. details can be worked out if a proposal is fundamentally reasonable. just my two cents.
< wumpus>
are there such disparete, incompatible ideas about activation parameters then, that there's fear no one will find agreement?
< luke-jr>
wumpus: it seems there is consensus on everything except LOT
< luke-jr>
(which is fairly even split)
< michaelfolkson>
luke-jr wumpus: Again in terms of effective NACKs from Core contributors it was more one sided in favor of LOT=false
< wumpus>
right
< michaelfolkson>
But agreed, no clear community consensus
< wumpus>
it didn't seem it would be so difficult for taproot
< luke-jr>
I don't think it's even related to taproot itself at this point
< wumpus>
i suppose everyone discussing activation parameters at leas has in common that they want it activated :)
< jeremyrubin>
luke-jr: sorry was looking for my last comments; back on july 17th 2020 I agreed that LOT=true makes much more sense
< jeremyrubin>
i haven't seen any arguments since then to have changed my mind substantially
< jeremyrubin>
(in ##taproot-activation)
< michaelfolkson>
Lots of light support for LOT=true in the meeting too jeremyrubin. Would you effectively NACK LOT=false?
< sipa>
can we keep the discussion itself elsewhere?
< michaelfolkson>
Sure. To ##taproot-activation if you have views
< sipa>
someone come up with a proposal, send it to the list, and open a PR
< warren>
I might have missed something but was there a TODO list for switching to guix for 0.22?
< bitcoin-git>
[bitcoin] jonasschnelli opened pull request #21228: Avoid comparision of integers with different signs (master...2021/02/minertest_U_fix) https://github.com/bitcoin/bitcoin/pull/21228
< luke-jr>
warren: I think that was at last meeting
< luke-jr>
although after struggling with Guix for a few more days after that, I don't see the point, it seems to only have negatives, no real improvements in practice