XSF Editor Team - 2023-03-09

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

I find this useful when serving new changes to be discussed

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

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

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?

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

jonas': ist that correct? --^

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

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

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

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)

Guus: --^

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

I don't know anything about publishing, 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) I've merged some things but not done the corresponding publish, yes.

Does the move to experimental require a new revision block?

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

but only if the current version block was already published

which it was not in case of XEP-0388

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

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

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

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

(which I am not)

That's not right.

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

Kev: why?

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

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

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

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

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

how's this?

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.

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

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

sorry wrong movie

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

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.

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

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

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

now: dinner.

I hope your dinner is no work :)

> 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