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.
jonas’
indeed
jonas’
you need to build that image locally and push it to some obscure registry hosted on gitlab.com
jonas’
for which you probably don't have +w
Kev
Just found the repo in the create scripts, at least, ta.
Kev
Ok, I'll adapt that slightly, for the moment.
jonas’
sorry for that, that's an artificat of the failed attempt to streamline stuff over at gitlab.com✎
jonas’
sorry for that, that's an artifact of the failed attempt to streamline stuff over at gitlab.com ✏
Kev
Not a problem, I just need to Do A Thing.
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.
Right, looks like I'm now set up to publish XEPs and attic in one go.
pep.has left
pep.has joined
jonas’
woop woop
jonas’
you probably won't continue my commit message history in the attic though
Kev
I did not.
Kev
I looked at it. I thought 'that's cute', and then continued to be lazy.
me9has joined
Link Mauvehas left
Kevhas left
Kevhas joined
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?
Kev
I'm entirely happy with doing the docker build locally, TBH.
Kev
It's one command I need to run to get it built and deployed.
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.
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.
Kev
All the checks when triaging is a nuisance.
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
Kev
I'll share my script ;)
moparisthebest
Plus all editors have to also be in iteam?
Kev
The deployment's automatic.
Kev
Anyway, I'm not saying we can't automate this bit further. Just that it's not the pain point.
moparisthebest
Right others seem higher priority, just seems a bit like death by a thousand cuts
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 :)
moparisthebest
If you want to review my triage.sh PR feel free :D
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.
tmolitorhas left
tmolitorhas joined
jonas’
moparisthebest, except for the missing approver thing, lgtm
Link Mauvehas joined
Tobihas left
Tobihas joined
Tobihas left
Tobihas joined
Tobihas left
Tobihas joined
Tobihas left
Tobihas joined
stpeterhas joined
Tobihas left
Tobihas joined
Tobihas left
Tobihas joined
moparisthebest
jonas’: trying to fix that in that other MR, applying approver to all of them, then this can just be a hard error
moparisthebest
Thanks for reviewing!
Tobihas left
Tobihas joined
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?
Kev
I think the latter would be ok, it's a forcing function.
Zashhas joined
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
soulhas left
stpeterhas left
soulhas joined
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
moparisthebest
But gotta make sure they all have them before that can be done