XSF Editor Team - 2023-03-09


  1. pep.

    Is there a way to include commit information when building xeps? Last commit to have modified the file.

  2. pep.

    I find this useful when serving new changes to be discussed

  3. pep.

    (stuff I build locally and upload somewhere for everyone to see)

  4. pep.

    But I'd also find useful to have this info available in XEPs in general anyway

  5. Guus

    I've dutifully followed TRIAGING and applied the "Needs Editor Action" label to https://github.com/xsf/xeps/pull/1214 - but is there anything that I can do to move this along?

  6. tmolitor

    Guus: I guess adding a commit putting the xep back into experimental (if that's the only editor action needed)

  7. tmolitor

    jonas': ist that correct? --^

  8. Guus

    tmolitor: yeah, if it's something easy like that, I'm happy to. I'm just not sure exactly what's needed.

  9. Guus

    Apart from processes to be completed, is there stopping something from this being moved to council?

  10. tmolitor

    no, no stoppers...it is not even needed to move that to council because it's an experimental xep and the original author already gave his okay, so it's fine to just be merged and published afaik

  11. tmolitor

    speaking of publishing the xep: XEP-0353 is merged, but not yet published, right? (the update announcement on standards@ and the update of the html rendering on xmpp.org is still missing)

  12. tmolitor

    Guus: --^

  13. Kev

    > Guus: I guess adding a commit putting the xep back into experimental (if that's the only editor action needed) I don't have time to look right now, but if the only thing blocking on triage is that it needs to bump to experimental again from deferred, adding that block speeds things up, yes.

  14. Guus

    I don't know anything about publishing, tmolitor

  15. Kev

    > speaking of publishing the xep: XEP-0353 is merged, but not yet published, right? (the update announcement on standards@ and the update of the html rendering on xmpp.org is still missing) I've merged some things but not done the corresponding publish, yes.

  16. Guus

    Does the move to experimental require a new revision block?

  17. Kev

    Moving to experimental requires changes to the XEP, and changes to the XEP require a new version block.

  18. tmolitor

    but only if the current version block was already published

  19. tmolitor

    which it was not in case of XEP-0388

  20. tmolitor

    > Moving to experimental requires changes to the XEP, and changes to the XEP require a new version block.

  21. tmolitor

    so changing just the status to experimental should suffice for XEP-0388

  22. Guus

    This is my attempt: https://github.com/xsf/xeps/pull/1214/commits/7615b5070526cc2a36a65f4ef9411cfc4ebb5815

  23. Guus

    note that I'm casually identifying myself as an editor here.

  24. Guus

    (which I am not)

  25. Kev

    That's not right.

  26. tmolitor

    and because the newest commit of a xep should always contain a revision block, adding the "experimental" to my pull request branch and then doing a squashing merge of that branch should be fine

  27. tmolitor

    Kev: why?

  28. Kev

    Because Guus has pushed a 0.4.1 change that does nothing but change from Deferred to Experimental, when there was never a published 0.4.0

  29. tmolitor

    yes, I thought you meant my comment about just changing the 0.4.0 to also include the change back to experimental...

  30. Kev

    I'm saying that Guus's commit is wrong.

  31. Guus

    I'll remove the revision block and add a LI on the last one.

  32. tmolitor

    okay, so Guus should do what I suggested above (create a new commit containing that change but without a version block, then squash merge the whole branch)?

  33. Guus

    how's this?

  34. Kev

    Guus shouldn't merge anything. But if that branch contains a single commit that both adds the right version block and changes it from Deferred to Experimental, I believe it'll be ready to merge.

  35. tmolitor

    okay, that's nearly the same, just Guus stopping processing before merging that and someone different (you, Kev?) doing the squashing merge...

  36. emus

    Shouldnt we just try it? I mean, if triage fails (?) we can manually revert and correct the script?

  37. emus

    sorry wrong movie

  38. Kev

    I have no idea what you're talking about, sorry.

  39. Kev

    And I'm sorry I'm not being as patient as I should today. If anyone has a spare ten or twenty hours in the day, please send them, I need them.

  40. Guus

    Hey, don't start hogging spare hours all by yourself!

  41. Guus

    it's fine, Kev. We've all been there.

  42. Guus

    as for me: trying to walk that balance between being helpful and causing more work is tricky.

  43. Guus

    now: dinner.

  44. tmolitor

    I hope your dinner is no work :)

  45. emus

    > Kev: > 2023-03-09 05:32 (GMT+01:00) > I have no idea what you're talking about, sorry. I thought it was about automation stuff