XSF Editor Team - 2023-01-26


  1. Kev

    Right, no sign of the published XEPs. Anyone know how they're deployed? The docs say https://hub.docker.com/r/xmppxsf/xeps/builds/ but that seems to not be true.

  2. jonas’

    indeed

  3. jonas’

    you need to build that image locally and push it to some obscure registry hosted on gitlab.com

  4. jonas’

    for which you probably don't have +w

  5. Kev

    Just found the repo in the create scripts, at least, ta.

  6. Kev

    Ok, I'll adapt that slightly, for the moment.

  7. jonas’

    sorry for that, that's an artificat of the failed attempt to streamline stuff over at gitlab.com

  8. jonas’

    sorry for that, that's an artifact of the failed attempt to streamline stuff over at gitlab.com

  9. Kev

    Not a problem, I just need to Do A Thing.

  10. Kev

    I don't see a lot of value in me fighting with a registry to upload a manual image when I could just upload directly to eos2, so I'm going to do that.

  11. jonas’

    how would you upload to eos2 directly?

  12. Kev

    docker save ... | gzip | pv | ssh eos2 docker load

  13. jonas’

    right

  14. jonas’

    I never do that because it doesn't dedupliate the lower layer

  15. jonas’

    which matters if you have 1 MB/s uplink :D

  16. Kev

    Maybe it's a stupid idea and I'm about to break everything. I guess we'll find out in a momen ;)

  17. Kev

    Maybe it's a stupid idea and I'm about to break everything. I guess we'll find out in a moment :)

  18. jonas’

    no, sounds about right

  19. Kev

    Alright, I now have a local script to do the build, upload and deploy.

  20. Kev

    Next step, I guess, working out if any cron or whatever on eos2 is going to overwrite it with the old version.

  21. Kev

    Oh, good, it looks like there's multiple things trying to serve xeps.

  22. jonas’

    yes, there is a cronjob

  23. jonas’

    I re-enabled it the other day

  24. Kev

    Worse, there's a cronjob that's serving xeps in a different manner.

  25. jonas’

    uhuh?

  26. jonas’

    did I mess that up?

  27. jonas’

    (maybe iteam@?

  28. jonas’

    (maybe iteam@?)

  29. Kev

    I don't know.

  30. jonas’

    (maybe move this to iteam@?)

  31. Kev

    Right, looks like I'm now set up to publish XEPs and attic in one go.

  32. jonas’

    woop woop

  33. jonas’

    you probably won't continue my commit message history in the attic though

  34. Kev

    I did not.

  35. Kev

    I looked at it. I thought 'that's cute', and then continued to be lazy.

  36. moparisthebest

    jonas’, Kev: should this eos2 instead run something like https://github.com/adnanh/webhook so merging an MR could tell it to pull and rebuild?

  37. Kev

    I'm entirely happy with doing the docker build locally, TBH.

  38. Kev

    It's one command I need to run to get it built and deployed.

  39. Kev

    Unless I'm missing something, the tooling once the PRs are ready to merge is pretty ok, it's all the stuff before that that's nuisanceful.

  40. Kev

    Next time I do a deploy I'll add a couple of extra lines to my local shell script, and everything'll be fine from that point of view.

  41. Kev

    All the checks when triaging is a nuisance.

  42. moparisthebest

    > Next time I do a deploy I'll add a couple of extra lines to my local shell script, and everything'll be fine from that point of view. But only for you, not for any other or future editors

  43. Kev

    I'll share my script ;)

  44. moparisthebest

    Plus all editors have to also be in iteam?

  45. Kev

    The deployment's automatic.

  46. Kev

    Anyway, I'm not saying we can't automate this bit further. Just that it's not the pain point.

  47. moparisthebest

    Right others seem higher priority, just seems a bit like death by a thousand cuts

  48. Kev

    At least for me, the deployment now of xeps and attics is fairly painless (as long as I don't discover gremlins next time).But the bit where we interact with people on PRs is...not painless :)

  49. moparisthebest

    If you want to review my triage.sh PR feel free :D

  50. Kev

    I've been mostly leaving MattJ for that, as he's got a better grip of where we're going with tooling, but I'll take a look, thanks.

  51. jonas’

    moparisthebest, except for the missing approver thing, lgtm

  52. moparisthebest

    jonas’: trying to fix that in that other MR, applying approver to all of them, then this can just be a hard error

  53. moparisthebest

    Thanks for reviewing!

  54. Kev

    I haven't looked, but does this error because there are XEPs that don't have approver, or error if a *changed* XEP doesn't have approver?

  55. Kev

    I think the latter would be ok, it's a forcing function.

  56. Zash

    Hello, I'd just like to be sure https://xmpp.org/extensions/inbox/xep-sla.html doesn't fall between the chair shuffle of the new council and editor constellation. https://logs.xmpp.org/council/2023-01-04?p=h#2023-01-04-90f98d9660c9c364

  57. moparisthebest

    Kev: it does different things based on whether the approver of the changed xep is council or board, and has an ugly "unknown" branch that should be deleted imho

  58. moparisthebest

    But gotta make sure they all have them before that can be done