XSF Discussion - 2022-02-19

Sam, FWIW the "easy" mitigation around caps poisoning is to have a per-jid caps cache

that negates some if not most of the usefulness of caps, but at least it is safe

(hence caps2 though)

Yah, I suspect that's what I'll have to do.

I should look into caps2 again; I have an old implementation lying around somewhere but haven't read it in ages. I wonder if it solved the original problem that I ran into this morning that made me have to restructure every damn thing.

does anyone know where i can buy cc

sky, https://smile.amazon.com/ccbeanie-Knitted-Headband-Headwrap-Earwarmer/dp/B07H42G87Q/

I mean credit card

then a bank probably

Good monring morap, you ping me when you are ready, ok?

emus, I just noticed you squash multiples commits together when accepting a PR on xmpp.org, this loses all of the commit history when not using the GitHub web UI.

I would recommend you to either to a fast-forward rebase, or do merge commits instead.

I personally prefer the former, but both are preferable to losing history imo.

defintely, that said, merge commits ftw :)

Also, when is the website getting rebuilt? is it weekly?

Manually by iteam

Am on phone, computer asleep.

I can do it

Link Mauve: But most of those PRs are small and the newsletter has a lot of minor stuff

I dont wanna bloat the commit history

That’s a bad reason imo, keeping the history readable by keeping separate changes separate is imo worth more than keeping the number of commits low.

So you argue to never squash?

moparisthebest: seen my message?

Yes, if you aren’t pleased with a particular PR’s commits, ask the author to reorder them or something, but not squash them yourself.

My most recent PR was correctly split in one commit adding xmpp-rs, one commit adding the Rust logo to the homepage.

And I’ve seen other PRs with many more commits getting mashed together into something very hard to review after the fact.

🤔 ok I will try to improve this an take a look for thid