-
moparisthebest
jonas’, MattJ first go https://github.com/xsf/xeps/pull/1255
- jonas’ looks
-
moparisthebest
on a different topic, I have a proposal here: https://github.com/xsf/xeps/issues/1236#issuecomment-1360252549
-
jonas’
Thanks. Skimmed, will have to think on that.
-
moparisthebest
tl;dr find a way to use existing git viewing tools to solve the attic for us
-
jonas’
yeah
-
jonas’
my issue is that we sometimes have more than one commit for a single document between revision blocks
-
jonas’
i.e. it's not obvious which state version X of document Y is just by looking at the commit log
-
jonas’
unless you also look for revision blocks
-
jonas’
but that's effectively the tagging issue really
-
jonas’
ah, there's something else, too.
-
moparisthebest
going forward, all changes are going to be required to have new version blocks right?
-
moparisthebest
in the past, oh well too late
-
jonas’
yes, but they're not required to do all changes in a single commit
-
jonas’
you can have multiple commits and then "seal them off" with a commit adding a revision block
-
jonas’
but as I just wrote on github: your idea is nice for viewing, but I don't see how it helps with deduplicating sending emails✎ -
jonas’
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 ✏
-
moparisthebest
maybe if people want emails they subscribe to github for commit notifications?
-
jonas’
no.
-
jonas’
we cannot subscribe standards@ to commit notifications, can we
-
jonas’
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.
-
jonas’
and commit notifications don't substitute "LAST CALL" things, which are also handled `send-updates.py` based on XEP state changes
-
moparisthebest
"sealing them off" would be "merging a PR" right?
-
jonas’
no, sealing them off would be a commit with a revision block followed by no further commits touching that file in a single PR.
-
jonas’
please see https://github.com/xsf/xeps/issues/1238 and https://github.com/xsf/xeps/issues/1239 for thoughts on that
-
moparisthebest
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" ?
-
jonas’
squashing PRs is evil
-
jonas’
</ideology>
-
moparisthebest
not doing it introduces problems
-
jonas’
that's too radical a change for me to accept right now
-
jonas’
and what I also don't like is how hard that ties us into github
-
moparisthebest
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
-
jonas’
and commit notifications are still not as readable as the current emails
-
moparisthebest
(ie, *they* are expected to squash them)
-
jonas’
they wouldn't include links to the rendered version for instance
-
jonas’
that's even worse, moparisthebest ;)
-
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
-
moparisthebest
it's pretty common for each PR to be required to only have 1 commit
-
jonas’
let me try to remember why I didn't just do that in gitlab ci
-
jonas’
moparisthebest, not where I live/work
-
jonas’
but aaanyway
-
jonas’
right, race conditions
-
moparisthebest
what's a race?
-
jonas’
emails should only be sent after the build is over. the build takes longer than a few seconds. merging multiple PRs sequentially causes all kinds of fun then✎ -
jonas’
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 ✏
-
moparisthebest
the build is only going to send emails to the latest version right?✎ -
moparisthebest
the build is only going to send emails with links to the latest version right? ✏
-
jonas’
it depends™
-
jonas’
well, yes
-
jonas’
though the notifications include the revision block notice
-
jonas’
and one would expect emails for all versions
-
moparisthebest
well if the git viewer can render xeps then there is no build step, and we can link directly to versions
-
jonas’
the git viewer cannot though
-
jonas’
and the XSF won't host a git server
-
moparisthebest
that was my proposal, have a git viewer that can
-
jonas’
yeah, no, we're not going to host a forge, sorry
-
jonas’
(iteam member hat)
-
moparisthebest
viewer does not imply forge
-
moparisthebest
also github can render markdown and we can convert xml to markdown automatically
-
jonas’
I think I'm getting too tired of this
-
jonas’
I'll have to give this some thought
-
jonas’
(10:30 pm local time, bedtime since 30mins really)
-
jonas’
(should head there)
-
moparisthebest
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
-
moparisthebest
but yes get some sleep, thanks for the pointers today
-
jonas’
yw
-
jonas’
thanks for the PR!
-
jonas’
(you got comments on that one, too)
-
moparisthebest
addressed some of those and commented on the others, please feel free to get sleep before looking again :D
-
moparisthebest
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