XSF Editor Team - 2022-12-20

jonas’, MattJ first go https://github.com/xsf/xeps/pull/1255

on a different topic, I have a proposal here: https://github.com/xsf/xeps/issues/1236#issuecomment-1360252549

Thanks. Skimmed, will have to think on that.

tl;dr find a way to use existing git viewing tools to solve the attic for us

yeah

my issue is that we sometimes have more than one commit for a single document between revision blocks

i.e. it's not obvious which state version X of document Y is just by looking at the commit log

unless you also look for revision blocks

but that's effectively the tagging issue really

ah, there's something else, too.

going forward, all changes are going to be required to have new version blocks right?

in the past, oh well too late

yes, but they're not required to do all changes in a single commit

you can have multiple commits and then "seal them off" with a commit adding a revision block

but as I just wrote on github: your idea is nice for viewing, but I don't see how it helps with automatically sending emails ✏

maybe if people want emails they subscribe to github for commit notifications?

no.

we cannot subscribe standards@ to commit notifications, can we

and also 'you can have multiple commits and then "seal them off" with a commit adding a revision block', that would be a significant amount of noise.

and commit notifications don't substitute "LAST CALL" things, which are also handled `send-updates.py` based on XEP state changes

"sealing them off" would be "merging a PR" right?

no, sealing them off would be a commit with a revision block followed by no further commits touching that file in a single PR.

please see https://github.com/xsf/xeps/issues/1238 and https://github.com/xsf/xeps/issues/1239 for thoughts on that

is there a reason to not just squash PRs so 1 PR == 1 commit and then it's a simple matter of "when a PR is merged, send an email for each XEP updated" ?

squashing PRs is evil

</ideology>

not doing it introduces problems

that's too radical a change for me to accept right now

and what I also don't like is how hard that ties us into github

but ok pretend I didn't say *we* squash them and instead the policy is just that the PR author ensures there is only 1 commit

and commit notifications are still not as readable as the current emails

(ie, *they* are expected to squash them)

they wouldn't include links to the rendered version for instance

that's even worse, moparisthebest ;)

yea I don't want to be tied to github either, but with any system merging a PR lets us run some code then, which would send an email for each XEP changed

it's pretty common for each PR to be required to only have 1 commit

let me try to remember why I didn't just do that in gitlab ci

moparisthebest, not where I live/work

but aaanyway

right, race conditions

what's a race?

emails should only be sent after the build is over. the build takes longer than a few seconds. merging multiple PRs in parallel then causes all kinds of fun then ✏

the build is only going to send emails with links to the latest version right? ✏

it depends™

well, yes

though the notifications include the revision block notice

and one would expect emails for all versions

well if the git viewer can render xeps then there is no build step, and we can link directly to versions

the git viewer cannot though

and the XSF won't host a git server

that was my proposal, have a git viewer that can

yeah, no, we're not going to host a forge, sorry

(iteam member hat)

viewer does not imply forge

also github can render markdown and we can convert xml to markdown automatically

I think I'm getting too tired of this

I'll have to give this some thought

(10:30 pm local time, bedtime since 30mins really)

(should head there)

anyway even if we continue doing builds the current way I think we can avoid races just by only doing 1 build + email at a time

but yes get some sleep, thanks for the pointers today

yw

thanks for the PR!

(you got comments on that one, too)

addressed some of those and commented on the others, please feel free to get sleep before looking again :D

on the other topic, I really think 1 PR == 1 change == 1 commit is the right thing to do here and vastly simplifies everything, and I can't come up with a reason it wouldn't work for any change, but that's just my gut feeling, let me know what you think