XSF Editor Team - 2022-12-20

  1. emus has left

  2. emus has joined

  3. Millesimus has left

  4. Millesimus has joined

  5. wurstsalat has left

  6. Millesimus has left

  7. Millesimus has joined

  8. Millesimus has left

  9. Millesimus has joined

  10. Millesimus has left

  11. Millesimus has joined

  12. Millesimus has left

  13. Millesimus has joined

  14. Millesimus has left

  15. Millesimus has joined

  16. Millesimus has left

  17. Millesimus has joined

  18. Millesimus has left

  19. Millesimus has joined

  20. Millesimus has left

  21. Millesimus has joined

  22. Millesimus has left

  23. soul has joined

  24. Millesimus has joined

  25. Millesimus has left

  26. Millesimus has joined

  27. Tobi has joined

  28. soul has left

  29. soul has joined

  30. MSavoritias (fae,ve) has joined

  31. wurstsalat has joined

  32. moparisthebest has left

  33. moparisthebest has joined

  34. MSavoritias (fae,ve) has left

  35. soul has left

  36. soul has joined

  37. MSavoritias (fae,ve) has joined

  38. soul has left

  39. soul has joined

  40. soul has left

  41. soul has joined

  42. winfried has left

  43. tmolitor has left

  44. tmolitor has joined

  45. moparisthebest has left

  46. moparisthebest has joined

  47. winfried has joined

  48. Kev has joined

  49. Kev has left

  50. Kev has joined

  51. Daniel has left

  52. Daniel has joined

  53. MSavoritias (fae,ve) has left

  54. Daniel has left

  55. Daniel has joined

  56. Daniel has left

  57. MSavoritias (fae,ve) has joined

  58. MSavoritias (fae,ve) has left

  59. MSavoritias (fae,ve) has joined

  60. Daniel has joined

  61. Daniel has left

  62. Daniel has joined

  63. MSavoritias (fae,ve) has left

  64. MSavoritias (fae,ve) has joined

  65. Daniel has left

  66. Daniel has joined

  67. tmolitor has left

  68. tmolitor has joined

  69. MSavoritias (fae,ve) has left

  70. moparisthebest

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

  71. Kev has left

  72. jonas’ looks

  73. moparisthebest

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

  74. jonas’

    Thanks. Skimmed, will have to think on that.

  75. moparisthebest

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

  76. jonas’


  77. jonas’

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

  78. jonas’

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

  79. jonas’

    unless you also look for revision blocks

  80. jonas’

    but that's effectively the tagging issue really

  81. jonas’

    ah, there's something else, too.

  82. moparisthebest

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

  83. moparisthebest

    in the past, oh well too late

  84. jonas’

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

  85. jonas’

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

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

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

  88. moparisthebest

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

  89. jonas’


  90. jonas’

    we cannot subscribe standards@ to commit notifications, can we

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

  92. jonas’

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

  93. moparisthebest

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

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

  95. jonas’

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

  96. 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" ?

  97. jonas’

    squashing PRs is evil

  98. jonas’


  99. moparisthebest

    not doing it introduces problems

  100. jonas’

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

  101. jonas’

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

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

  103. jonas’

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

  104. moparisthebest

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

  105. jonas’

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

  106. jonas’

    that's even worse, moparisthebest ;)

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

  108. moparisthebest

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

  109. jonas’

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

  110. jonas’

    moparisthebest, not where I live/work

  111. jonas’

    but aaanyway

  112. jonas’

    right, race conditions

  113. moparisthebest

    what's a race?

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

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

  116. moparisthebest

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

  117. moparisthebest

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

  118. jonas’

    it depends™

  119. jonas’

    well, yes

  120. jonas’

    though the notifications include the revision block notice

  121. jonas’

    and one would expect emails for all versions

  122. moparisthebest

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

  123. jonas’

    the git viewer cannot though

  124. jonas’

    and the XSF won't host a git server

  125. moparisthebest

    that was my proposal, have a git viewer that can

  126. jonas’

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

  127. jonas’

    (iteam member hat)

  128. moparisthebest

    viewer does not imply forge

  129. moparisthebest

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

  130. jonas’

    I think I'm getting too tired of this

  131. jonas’

    I'll have to give this some thought

  132. jonas’

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

  133. jonas’

    (should head there)

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

  135. moparisthebest

    but yes get some sleep, thanks for the pointers today

  136. jonas’


  137. jonas’

    thanks for the PR!

  138. jonas’

    (you got comments on that one, too)

  139. moparisthebest

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

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

  141. Kev has joined

  142. Kev has left

  143. Kev has joined

  144. tmolitor has left

  145. tmolitor has joined

  146. Kev has left

  147. moparisthebest has left

  148. moparisthebest has joined

  149. Tobi has left

  150. Tobi has joined

  151. wurstsalat has left