<nkaretnikov>
sedited: saw your post on PR reviews. my take: to improve merge velocity, Core needs to get to a point where green CI = good to merge. if you’re worried about functionality breaking, add more of those tests. if you’re worried about memory/security issues, add those tests. PRs also need to be small and self-contained, which would allow scanning them quickly and will simplify reverts if necessary. there should also
<nkaretnikov>
be less stress associated with merging something that could be potentially wrong. there should be canary/RC deployments that undergo additional long-term checks/testing (automated) before they are promoted to releases. the Core team needs to define a policy for that to make it explicit for contributors. the process should be distributed, where PR authors are expected to write tests themselves. also: there needs to be
<nkaretnikov>
testing, as mentioned before. I don’t know if this already exists, but the PR discoverability process could potentially be improved as well. PRs could be tagged appropriately based on the subsystem, importance, size. That would help first merge those that are high-value and easy.
<nkaretnikov>
clear guidance on what comments are blockers vs. nitpicks during review. this should help getting a small version of a change in before other points can be aligned on. I had this comment during one of the recent LevelDB PRs, people share screenshots, but all that should really be part of tests. Then it’s clear signal that the behavior is fixed. If long-term testing is needed, this should be done as part of canary
<nkaretnikov>
sedited: if you’re not opposed to this idea, i can look into getting some of this stuff in: defining a policy doc in a GH template, looking at labels, etc. because the other options are: getting more people involved (from where?) or for the existing contributors to somehow become faster/better reviewers (I think this is also not going to happen because everyone is already doing their best), so the only answer I see
<nkaretnikov>
is automation.
<sedited>
I don't think automation, additional process policy, or nits are the problem here.
<nkaretnikov>
another thing that delays reviews is the back-and-forth process. getting the relevant people in a call could help this because it reduces time of this back-and-forth loop. you can ask people directly and make a decision on the spot. but it might not be possible with all contributors.
<sedited>
on the topic of labels, I've been meaning to ask what people would think of me assigning them more liberally.
<nkaretnikov>
sedited: then it seems like you have a guess on what the problem might be. could you share that? you said, for example, that PR review groups didn’t work that well. i was not involved at the time, so would like to know why.
<sedited>
I think them no longer being done is a good indication that they were not working.
enochazariah has quit [Ping timeout: 248 seconds]
<lightlike>
What "post on PR reviews" are you talking about?
enochazariah has joined #bitcoin-core-dev
memset has quit [Remote host closed the connection]
memset has quit [Remote host closed the connection]
<bitcoin-git>
[bitcoin] rustaceanrob opened pull request #35625: test: Constrain optionalT operator by streamability (master...26-6-30-optional) https://github.com/bitcoin/bitcoin/pull/35625
<sipa>
nkaretnikov: i think much of the struggles with PR review (especially for larger changes) are not of the form "is this safe / does this have enough tests", but of the form "is this a good idea" / "should we go in this direction" / "is this worth spending time on as a project (incl. the follow-up maintenance burden)". Without clarity on those, it's often unclear whether a PR will go somewhere at
<sipa>
all, and as a secondary effects, discourages people from...
<sipa>
spending time on it
deadmanoz has joined #bitcoin-core-dev
GoldenGoose has quit [Ping timeout: 265 seconds]
ozdeadman has quit [Ping timeout: 264 seconds]
<stickies-v>
pinheadmz: what's the current best way to flag when something looks like an LLM issue/PR? leave a comment? drop the link here?
bugs_ has joined #bitcoin-core-dev
cfields has joined #bitcoin-core-dev
GoldenGoose has joined #bitcoin-core-dev
GoldenGoose_ has joined #bitcoin-core-dev
GoldenGoose has quit [Read error: Connection reset by peer]
<pinheadmz>
you DM me on signal if you like. You can also comment on one of the ongoing issues or discusisons i.e. https://github.com/bitcoin-core/meta/discussions/33 or if its a bigger issue with a user or trend or something you can start a new discussion or issue in that repo
<pinheadmz>
or drop here so it reaches more ban hammers
<pinheadmz>
another thing that works is commenting that it looks like "AI slop" -- which the moderator bot i have thinks is inflamatory and reports to me on telegram X-D