XSF Discussion - 2023-02-09

  1. moparisthebest

    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/

  2. Guus

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

  3. Guus

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

  4. Guus

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

  5. Daniel

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

  6. Daniel

    Or I was put on hold until the situation has been cleared

  7. Daniel

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

  8. Guus

    Thanks Daniel

  9. Guus

    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?

  10. Guus


  11. moparisthebest

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

  12. Guus

    moparisthebest it uses grep thus qualifies. ;)

  13. Kev

    > 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.

  14. Kev


  15. moparisthebest

    Or, run the triage.sh script...

  16. Guus

    oh, I'll try triage.sh

  17. Guus

    I appear not smart enough to use that tool

  18. Guus

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

  19. jonas’

    moparisthebest: ^

  20. 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?

  21. Guus

    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.

  22. Guus

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

  23. moparisthebest

    Guus: but all changes have been committed?

  24. Guus

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

  25. moparisthebest

    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)

  26. Guus

    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.

  27. moparisthebest

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

  28. Guus


  29. moparisthebest

    So not the same person then :D

  30. Guus


  31. Guus

    computer says no!

  32. Guus

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

  33. Guus

    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?

  34. Guus

    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.

  35. Guus

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

  36. moparisthebest

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

  37. moparisthebest

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

  38. Guus

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

  39. moparisthebest

    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 :)

  40. Guus

    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'.

  41. Guus

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

  42. moparisthebest

    The script does check that, if the git email matches

  43. Guus

    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.

  44. moparisthebest

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

  45. moparisthebest

    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

  46. Daniel

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

  47. Daniel

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

  48. Guus

    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)?

  49. Daniel

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

  50. Guus

    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.

  51. Guus

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

  52. moparisthebest

    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

  53. moparisthebest

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

  54. Guus

    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?

  55. moparisthebest

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

  56. moparisthebest

    If people are changing emails that much yell at them

  57. moparisthebest hides

  58. Daniel

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

  59. Daniel

    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

  60. Zash

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

  61. Zash

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

  62. Zash

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