XSF Discussion - 2023-02-09

here's the PoC of what I'd really like to see at joinxmpp.org as discussed earlier, rest of discussion on it will happen in the muc linked earlier: https://joinxmpp.moparisthe.best/

Does that automatically 'translate' the word 'jabber' from the original website into 'xmpp'? Nifty.

FAST has not yet progressed beyond the inbox, has it?

it disappeared from the spreadsheet of Doom (or I'm looking in the wrong place)

Guus: council has put it on hold until sasl2 is merged

Or it was put on hold until the situation has been cleared ✏

Thanks Daniel

I've removed the 'Needs Author' label from https://github.com/xsf/xeps/pull/1214, as it's current author signals that's desired. I've fixed the validation check that was failing. I'm not sure if this now qualifies for the 'Ready To Merge' label?

`</editor-impostering>`

Guus: for some definition of automatic https://joinxmpp.moparisthe.best/joinxmpp.sh

moparisthebest it uses grep thus qualifies. ;)

> I've removed the 'Needs Author' label from https://github.com/xsf/xeps/pull/1214, as it's current author signals that's desired. I've fixed the validation check that was failing. I'm not sure if this now qualifies for the 'Ready To Merge' label? As long as you follow the triaging instructions, you're welcome to do as much Editor Impostering as you want.

https://github.com/xsf/xeps/blob/master/docs/TRIAGING.md

Or, run the triage.sh script...

oh, I'll try triage.sh

I appear not smart enough to use that tool

```$ ./tools/triage.sh "XEP-0388: Rework whole spec, namespace bump" manual: no XEPs changed```

moparisthebest: ^

Guus: are you on a different branch where your change has been committed? Otherwise you have to send in commit and/or merge base?

moparisthebest: you need to remember that you need to talk to me s l o w l y if there's to be any chance of my following.

When I'm on the branch that introduces the change, I get: "error: cannot change xeps and add ProtoXEP in 1 PR"

Guus: but all changes have been committed?

`/tools/triage.sh "XEP-0388: Rework whole spec, namespace bump" 240bab773631a06572ab5ffdc3a01bbf4d1f42fd afd9c08a3a415d97fd8dcc593d36b4c6346b19d3` That seems to do something

My guess is: your master is behind, and by default that's what it diffs your current branch against (note: your local master, not origin/master)

instructing me to apply a needs-author tag, pending approval of either Dave or Thilo - yet Thilo is the one making the PR, so that approval seems implicit.

Is thilo's git commit email the same as the one in the XEP?

nope

So not the same person then :D

agreed.

computer says no!

And I had indeed neglected to reset my master branch to upstream's master - that explains my earlier issue.

But seriously: an author using a slightly different email seems to me like a common occurrence. Can we somehow override that in the triaging tool?

hmm... when I modify `xep.ent` to force the author's email to be the same as the commiter, it still complains about requiring an approval.

one of the other authors _did_ approve the PR. Does the script check for that?

I think we should either maintain a... I think git calls it a mailmap, or just correct author's emails in the XEPs

This script doesn't know GitHub exists, once it's merged it can be tied into github-actions that does though

authors rarely have just one email. Some kind of map might be preferable.

I would also prefer to merge the script as-is and add some mailmap functionality as a follow up but that's not my call :)

Right, so the script can't check yet if approval has indeed already been given - although in this case, I think approval is implicit, as the author is also one of the commiters. I'm a bit surprised that the script still suggests that approval is needed / should be tagged with 'needs-author'.

'this case' being where I modified the known email address of the author (in `xep.ent` to match the email used in the commit)

The script does check that, if the git email matches

Maybe it's just me not interpreting the output correctily, or doing something else wrong. In any case, I think that the manual action that I already did on the PR (add `needs-editor-action`) was correct.

Yea I think it only says needs approver if it actually does: https://github.com/xsf/xeps/pull/1255/files#diff-18b16945fcadc8a9d0ba1968094e7af2c2bfe017232ce6186b9d8801edbac972R202

At least unless there is a bug... But keep in mind it only knows about the email in the git commits and xep and they must be identical

If it makes the editors job easier it's not an unreasonable ask that commiter email matches the email in the xep

Yes people have different addresses. But you can use the same address in the same context (writing xeps)

moparisthebest: that script is hard for me to read, but, I think it's _reading_ the pr_authors from commits, but never comparing it against the list of approvers (thus never going to see that there's an implicit approval)?

Granted it doesn't work in this case but going forward we could easily mandate that

Daniel: I'm not sure if I agree that that's not an unreasonable ask - it seems like a cumbersome step to only facilitate automation. No hill for me to die on, but ... meh.

anyways, I'm off. The PR is in the correct state, so all this isn't blocking that particular change.

I think it's fair to say if you don't want to use the same email then *you* must maintain all your aliases in the mailmap file that currently doesn't exist

You are already making a PR, editing one more file won't hurt you

wouldn't that need additional verification, to prevent people (other than the author) from adding their email to the mapping under the alias of the author, to make the computer say yes?

Sure, but still does without it except on every MR ? This way editor only needs to glance when mailmap changes?

If people are changing emails that much yell at them

Idk I reckon a good amount of users won't even need mapping at all

Are occupant id + muc pm mind bendingly broken? If occupant id is the only true source of user identification in muc I want muc PM chats to be tied to occupant id even if the full jid changes underneath. But I can't actually send anything to an occupant id. This means there are race conditions when the full jid changes

Do we, can we, should we include the occupant id in the <{muc}x> in MUC PMs?

At some point we should try to swap the occupant id and the nickname, so the JID is clear of unstable user-entered info

Daniel, isn't it muc pm on its own being broken? and we knew that already 🙂