< bitcoin-git>
bitcoin/master f22a3ec fanquake: build: make macOS HOST in download-osx generic
< bitcoin-git>
bitcoin/master 5f18080 fanquake: Merge #21065: build: make macOS HOST in download-osx generic
< bitcoin-git>
[bitcoin] fanquake merged pull request #21065: build: make macOS HOST in download-osx generic (master...correct_host_download_osx) https://github.com/bitcoin/bitcoin/pull/21065
< bitcoin-git>
[bitcoin] fanquake opened pull request #21078: guix: only download sources for hosts being built (master...guix_selective_download) https://github.com/bitcoin/bitcoin/pull/21078
< bitcoin-git>
bitcoin/master 7777105 MarcoFalke: refactor: Move all command dependend checks to ExecuteWalletToolFunc
< bitcoin-git>
[bitcoin] MarcoFalke merged pull request #20715: util: Add ArgsManager::GetCommand() and use it in bitcoin-wallet (master...2012-argsCmd) https://github.com/bitcoin/bitcoin/pull/20715
< wumpus>
glozow: you just had the bad luck he latched on to your PR, we should probably have blocked him immediately after his attack on Randy
< wumpus>
but I tend to give people the benefit of the doubt initially and didn't know about the history
< wumpus>
it's disappointing that github still doesn't allow deleting inline comments
< fanquake>
Yes. Can't even access the editing dropdowns for the comments by the deleted account
< Kimi_>
wumpus, It's actually quite good. It's a simple file where you specify code style of your project. Like tabs vs spaces, indentation etc.
< Kimi_>
It's supported by many editors & IDEs
< Kimi_>
(MSVS, VSCode and many others)
< wumpus>
yea having a standard shared between editors makes me much more enthousiastic about it than things that are specific to one environment
< aj>
huh, that's cute
< wumpus>
fanquake: also noticed that, weird
< aj>
wumpus: looked into any of the decentralised bug-reports-in-git things? be kind-of neat to track PR reviews in git eventually
< wumpus>
aj: i looked at radicle but it didn't seem ready yet, haven't looked any further
< aj>
wumpus: there's https://github.com/MichaelMure/git-bug which seems a bit more ready; but it's just bugs -- doesn't seem like there's anything non-web for code review stuff
< wumpus>
thanks, will take a look! yes, code review seems to be the most difficult thing to offer, even github's own command-line client doesn't do it yet (though the API can)
< wumpus>
I mean, *inline code review*
< aj>
yeah
< aj>
i tried using the API to convert a text file to a review a while back, but it didn't work in confusing ways
< wumpus>
I guess old mailing list based open source development had some advantage in that regard, at least it's semi decentralized (only needs some way to distribute messages all-to-all), that said, mail is broken and with the volume of changes it'd become insane
< wumpus>
a replacement system really would need some UI and structured way to handle metadata
< wumpus>
and also moderation, it sucks but we can't do without that
< wumpus>
"works offline: in a plane or under the sea? Keep reading and writing bugs!" is nice, sure we can do this sort of by cloning bitcoin-gh-metadata but only in one way
< jnewbery>
it's nice that we can export all the metadata into bitcoin-gh-metadata, but it's only moderately useful until there are other bug trackers/review platforms that can import it and reconstruct all of the cross-references.
< jnewbery>
at least we have the export. If github gets so bad we can no longer usable, there's the possibility of reconstructing all the PR/review discussion
< jnewbery>
*we can no longer use it
< wumpus>
it's already useful for all kinds of local tooling/analysis, but yeah
< bitcoin-git>
[bitcoin] MarcoFalke opened pull request #21080: fuzz: Configure check for main function (take 2) (master...2101-fuzzTake2) https://github.com/bitcoin/bitcoin/pull/21080
< jnewbery>
agree about tooling/analysis. I use it to track review activity across the repo
< wumpus>
someone could theoretically make a GUI or CLI on top of it to edit things (e.g. add reviews, comments, PRs, issues), which can submit back the changes, then it'd 'only' need some kind of bot to validate, merge and reconcile changes for the project metadata--then again i'd really prefer not to get into writing this kind of tooling myself and hope someone else will make something usable
< wumpus>
it doen't seem terribly difficult but is a huge amount of work
< wumpus>
i'd say git already handles a lot of the hard parts
< wumpus>
i'm not convinced we need the full feature set of github, but something that handles only bugs is clearly not enough
< aj>
year PR review seems to be github (and gitlab and other similar fully centralised web-based things) or email
< bitcoin-git>
[bitcoin] brunoerg opened pull request #21081: test, refactor: fix the unreachable code at feature_taproot (master...taproot-test-return) https://github.com/bitcoin/bitcoin/pull/21081
< jonatack>
I wonder how different interaction would be, and if less moderation would be needed, without github's gamified activity graph and web browser "buttons to smash everywhere" UI...what if it was command line only...
< jonatack>
nowadays that may sound like a luddite, but hey
< jonatack>
(and the github notion of contributor list = commit list)
< wumpus>
jonatack: i agree that Microsoft kind of went over the top with this, too much focus on as you say, easy buttons to smash everywhere... i think a lot of stupid spam could be avoided by adding just a little bit more friction
< wumpus>
that said we also face persistent crazies with technical knowledge (e.g. zoltan yesterday) so i doubt it'd remove all need for moderation
< wumpus>
and some kind of GUI is nice, i mean if people with less cli know-how like GUI designers and users can somehow interact with the repositories, at least to propose issues/PRs and comment, that's good
< wumpus>
but for more advanced things such as merging, no UI is needed, we already use our own script after all
< wumpus>
no need for a big green click-me button 🙂 Iand don't get me started on the editing files through the website mis-feature
< wumpus>
also i'd actually prefer to configure the settings for repositories through a configuration file instead of a web interface
< aj>
hmm, how do you get the failure in #21039 to appear? on current master i just get the error, not assertion failure?
< bitcoin-git>
[bitcoin] MarcoFalke opened pull request #21082: refactor: Treat ArgsManager::Flags as uint32_t explicitly (master...2102-unsigned) https://github.com/bitcoin/bitcoin/pull/21082
< jnewbery>
at the risk of trying to design a distributed git review system here, I don't think you want the review data to be in the same repo as the code. It should be some external system that references the git repo.
< MarcoFalke>
PSA: All fuzz ci tests are failing due to a silent merge conflict in the integer sanitizer build
< jamesob>
Have a small fuzzer kink and a few comment updates on the highprio assumeutxo PR I'm going to address tonight
< jonatack>
jonasschnelli: do you want to add #20962?
< gribble>
https://github.com/bitcoin/bitcoin/issues/20962 | Alter the ChaCha20Poly1305@Bitcoin AEAD to the new specification by jonasschnelli · Pull Request #20962 · bitcoin/bitcoin · GitHub
< jonasschnelli>
not for now
< wumpus>
MarcoFalke: seems it's been needing rebase for two weeks
< MarcoFalke>
jamesob: The fuzzer is a problem in master, I think
< jonasschnelli>
I'd like to keep #15946
< jonatack>
jonasschnelli: ok. i thought it might be the blocker for bip324 impl
< wumpus>
jonatack: good to know, will have a look
< wumpus>
#topic Replacing github
< core-meetingbot>
topic: Replacing github
< jamesob>
Oh boy
< wumpus>
it's clear to me that this has to happen at some point but I don't think we found any projects ready for this
< jonasschnelli>
didn't we had this topic recently?
< sipa>
is there a concrete candidate to look at?
< wumpus>
if there are, I'd suggest first setting up a parallel / mirror, so that people can try
< fjahr>
It seems to be a constant topic since people get more and more frustrated
< wumpus>
switching is not going to be a flag day thing
< MarcoFalke>
sipa: Most of them seem "alpha" stage, so we'd have to play around with them
< luke-jr>
was there a concrete problem with GitLab?
< dongcarl>
Might this be an important enough thing that we should also look into building it ourselves / hacking existing open source solutions if none of the existing solutions work well enough?
< jamesob>
I suspect that there will be even more frustration with an alternative. The big argument would be that github is a worrisome dependency to have
< wumpus>
luke-jr: yes it's just another centralized thing
< promag>
wont the alternative have other issues?
< aj>
doing more tooling like gh-meta and ghwatch.py in the meantime seems like a good start?
< luke-jr>
wumpus: eh, as opposed to what?
< jamesob>
promag: right
< MarcoFalke>
Funny, if GitHub had a simple moderator queue or other means of spam protection and a stable website, we probably wouln't be talking about this
< wumpus>
aj: right, that's my idea
< fjahr>
Maybe there should be a wiki page to collect promising projects, then people post there experiences with mirrors
< fjahr>
Obviously this will be a long way
< wumpus>
luke-jr: git-appraise, radicle, git-bug, and various other systems that use git for propagation instead of relying (entirely) on central hosted infrastructure
< jonasschnelli>
aj: good point.
< jonasschnelli>
We can enhance the UX with custom tools
< MarcoFalke>
luke-jr: github and gitlab are hosted on the same infrastructure
< luke-jr>
MarcoFalke: same?
< jamesob>
We get a ton of utility out of the PR review flow; something that both has that and isn't centralized is going to be tough to find I think
< MarcoFalke>
Though, it might be easier to build a two-way-mirror for review comments for gitlab
< wumpus>
you can self-host gitlab or gitia etc but it'd be just another central server
< MarcoFalke>
luke-jr: google cloud?
< wumpus>
we need something that doesn't rely on a contributor to host something IMO
< wumpus>
aj: ok definitely makes sense to keep track of these in a wiki
< wumpus>
aj: this is too many for me to keep track of in my head :-)
< aj>
wumpus: yeah, they're super hard to search for too
< aj>
"git bug tracker"...
< fjahr>
MarcoFalke: I don't think the infrastructure is causing the frustrations. Maybe the first question is: is the focus to fix usability issues with GH or to decentralize or we want to do both at the same time
< wumpus>
I think we can do both at the same time
< wumpus>
primarily it needs a sane way of doing code review that *doesn't* lose comments
< wumpus>
this is the most serious issue with github, the collapsing comments and hidden diffs
< MarcoFalke>
fjahr: the infrastructure is the cause for centralization (and the risk of getting shut down at any time). IIRC some countries can't access github
< fjahr>
wumpus: maybe Gitlab doesn't lose comments, I don't know, but maybe that's a quick improvement on the usability front
< aj>
MarcoFalke: they recently announced they'd opened back up to some of those countries iirc
< wumpus>
fjahr: it's just not worth all the trouble of switching just to go to gitlab, you'll keep hopping
< MarcoFalke>
aj: "some" ;)
< wumpus>
aj: sure but who knows for how long the point is to not be dependent
< fjahr>
MarcoFalke: agree, centralization is the same at GL but it might fix the losing comments issue which most recent frustrations seemed to come from
< jamesob>
I'm guessing there'll be other unknown frustrations that pop up given GL isn't as actively developed as GH (AFAIK); and there is a pretty big cost to switching; CI integrations and drahtbot then need to be changed over
< jamesob>
IMO we should be sure we want to move to whatever we move to
< wumpus>
jamesob: I agree, if we switch it needs to be with something we have control over ourselves and plan to stick with for a long time
< aj>
MarcoFalke: i'm sure they'll remain proud to host it while it implies there's no alternatives to github?
< MarcoFalke>
aj: Typing as we speak
< aj>
heh
< luke-jr>
lol
< aj>
MarcoFalke: (missed opportunity to write "typing as i type")
< wumpus>
MarcoFalke: thanks!
< jnewbery>
so were the meetings that fanquake/theuni/moneyball had with GH just a waste of time? They listened and then didn't actually fix anything that's important for us?
< wumpus>
I think that concludes the topic for now, please look around if you find projects and try them out
< wumpus>
jnewbery: I don't think it's a waste of time to discover what your requirements are, whoever implements them
< jnewbery>
it's astonishing to me that one of the most important pieces of infrastructure for the open source community is owned by one of the most capitalized companies in the world and they can't even get a webpage to load
< luke-jr>
eh, one with a long history of deceptive warfare against open source
< aj>
jnewbery: i feel like you're overrating how competent humanity is at making computers work...
< wumpus>
I mean, yes, they didn't really do much, but talking about things like that was probably constructive anyway
< promag>
jnewbery: hold on, we have dark theme
< jnewbery>
wumpus: I'm not suggesting that they shouldn't have tried (and I'm very grateful that they did!), but github don't seem to have done anything about the problems.
< michaelfolkson>
It is Big Corp syndrome. Post acquisition the magic dies
< wumpus>
jnewbery: agree on that
< jonasschnelli>
didn't we had a direct contact with GitHub for a while?
< jamesob>
promag: lol
< * fjahr>
notes dark theme as hard requirement
< MarcoFalke>
jonasschnelli: fanquake does have direct contact but they ignore him pretty much
< jonasschnelli>
MarcoFalke: build up pressure?
< MarcoFalke>
(not judging them. They probably have paying clients)
< MarcoFalke>
jonasschnelli: I don't think open source is a priority for them
< sipa>
fjahr: GH has a dark theme
< jonasschnelli>
IMO GitHub has its flaws,.. but I don't see a better alternative and GH is certenly better than just tracking everything in a txt file
< wumpus>
I was a paying client but stopped paying when they were taken over by Microsoft
< fjahr>
sipa: yeah, just for the switching candidates ;)
< sipa>
ha yes
< promag>
I wonder how would gitlab behave with big prs with tens of comments and code
< sipa>
"tens of comments"
< jonatack>
I don't think GitHub is incentized to make the changes that we would like; I suspect maintaining a very uniform UX is key for GitHub, which might preclude per-repo configurable feature toggling and adjustable interaction friction
< sipa>
there's literally dozens of us!
< promag>
thousands
< sipa>
i think this discussion should move to the wiki; there isn't much to do here expect looking for alternatives and evaluating them
< jonatack>
GitHub's aim appears to be more faceBook than myspace in UX standardization
< promag>
their api probably returns everything no?
< sipa>
and getting back to the topic in a meeting in a few weeks maybe
< jonasschnelli>
I suggest that moneyball take up the contact again (as of #15847)
< michaelfolkson>
Can I tentatively ask a question about Taproot activation? It appears to me there are three options for lockinontimeout
< michaelfolkson>
Set to true in a Core release, set to false in a Core release or....
< michaelfolkson>
Community consensus that a Core release will have false and this will be followed by another Core release in 6 months with true (if needed)
< michaelfolkson>
Does that third option sound viable? Or would Core not want an instruction on what to do in 6 months?
< sdaftuar>
i would personally not agree with a commitment to release a consensus change at any specific point in the future.
< michaelfolkson>
Ok thanks, that's helpful sdaftuar
< michaelfolkson>
I don't want to discuss the merits of true, false. Go to #taproot-activation for that...
< michaelfolkson>
If anyone else has any thought on that let me know. Thanks
< michaelfolkson>
On that third option specifically
< jonatack>
fjahr: oh, agreed. i use gh pr now for reading review comments via the cli; as of v1.5 it shows all of the comments with one cli command and is far faster to use. just takes getting used to.
< fjahr>
Yeah, thanks, I need to give it another chance
< sipa>
sdaftuar: impressive, you have a 100% acceptance rate on your bitcoin SE answers
< sdaftuar>
i strive for perfection
< sdaftuar>
now if only my bip acceptance rate were so high... :)
< aj>
sdaftuar: maybe you should game the system and post your bips on stackoverflow?
< luke-jr>
sdaftuar: I can't suggest what to add to Motivation because I literally have no idea what the point is
< luke-jr>
so the point is to allow N*M light connections where being unsure means only N could be accepted?
< luke-jr>
(though IIRC our limits are due to FD set sizes and open fd limits currently?)
< sipa>
luke-jr: my understanding is this: we have a default inbound connection limit (125) which is based on the observation that every "fully fledged" connection has a significant impact on processing costs and bandwidth (among other things), so we can't just raise that without impacting worst-case performance of average nodes
< sipa>
if we instead knew for block-only connections (on the incoming side) that they'd *never* need transactions, the worst part is reduced, and perhaps it becomes acceptable to have more incoming connections per peer, given that some percentage of them are reserved for non-block-relaying connections
< sipa>
right now, the block-only nature of a connection is only known on the outbound side