XMPP Council - 2020-08-12


  1. Wojtek has joined
  2. Wojtek has left
  3. Lance has left
  4. Lance has joined
  5. stpeter has left
  6. pprrks has left
  7. Lance has left
  8. eta has left
  9. eta has joined
  10. pprrks has joined
  11. neox has left
  12. adiaholic_ has left
  13. adiaholic_ has joined
  14. Lance has joined
  15. Lance has left
  16. SouL has joined
  17. Tobias has joined
  18. Lance has joined
  19. raspbeguy has left
  20. raspbeguy has joined
  21. Lance has left
  22. Lance has joined
  23. bear has left
  24. marc0s has left
  25. marc0s has joined
  26. Lance has left
  27. Lance has joined
  28. sonny has left
  29. sonny has joined
  30. Lance has left
  31. sonny has left
  32. sonny has joined
  33. sonny has left
  34. sonny has joined
  35. sonny has left
  36. sonny has joined
  37. neox has joined
  38. Zash has left
  39. Zash has joined
  40. Lance has joined
  41. Lance has left
  42. debacle has joined
  43. eta has left
  44. eta has joined
  45. daniel has left
  46. Lance has joined
  47. Lance has left
  48. daniel has joined
  49. sonny has left
  50. sonny has joined
  51. sonny has left
  52. sonny has joined
  53. sonny has left
  54. sonny has joined
  55. Lance has joined
  56. Lance has left
  57. adiaholic_ has left
  58. Zash has left
  59. sonny has left
  60. sonny has joined
  61. adiaholic_ has joined
  62. sonny has left
  63. sonny has joined
  64. Lance has joined
  65. Zash has joined
  66. bear has joined
  67. Lance has left
  68. Wojtek has joined
  69. Lance has joined
  70. Ge0rG It's Council time!
  71. jonas’ 1) Roll Call
  72. jonas’ is here
  73. Zash here is
  74. Ge0rG
  75. jonas’ I need to switch devices
  76. jonas’ one minute please
  77. daniel Hi
  78. jonas’ here I am
  79. jonas’ 2) Agenda Bashing
  80. jonas’ sorry for the dreadful return of PR#971
  81. jonas’ any other complaints?
  82. Zash My coffee is cold!
  83. jonas’ … about the agenda
  84. jonas’ nice, now the work laptop is playing a snippet of metal in a very tight loop
  85. jonas’ trying suspend-then-hibernate wasn’t a good plan
  86. jonas’ ok, with that disturbance out of the way...
  87. jonas’ 3) Editor’s Update
  88. jonas’ - XEP-0045 v1.33.0 which removes 307 status code from service-caused kicks (as opposed to moderation-caused kicks)
  89. jonas’ 4) Items for Voting
  90. jonas’ 4a) Discuss whether PR#971 was rejected on false premises Sorry for this one. Flow brought up -- correctly -- that type="cancel" is special and we should discuss real quick if that changes anything for the folks who vetoed.
  91. jonas’ since XEP-0004 states: > a data form of type "cancel" SHOULD NOT contain any <field/> elements. I think some of the arguments in my original email regarding this topic may be invalid
  92. jonas’ since others based their vote on those arguments, please reconsider
  93. jonas’ and let me know if we should re-vote on this one
  94. Zash I'm staring at a diff right now .
  95. Ge0rG I'm still unconvinced whether removing text adds clarity.
  96. Zash So.
  97. jonas’ trivial example of where removing text adds clarity: > The form type "foo" has properties X. The properties Y and Z are only on form type "bar", which also has property X. Property W is found on both "foo" and "baz" types. vs. > "foo" has Property X and W, "bar" has property X, Y and Z, and "baz" has property W and X.
  98. jonas’ trivial example of where removing text adds clarity: > The form type "foo" has properties X. The properties Y and Z are only on form type "bar", which also has property X. Property W is found on both "foo" and "baz" types. vs. > "foo" has Property X and W, "bar" has property X, Y and Z, and "baz" has property W only.
  99. jonas’ or something similar, you get the gist :)
  100. daniel I'll read this again
  101. daniel The diff format with extremely long lines also makes this super hard to read
  102. Ge0rG jonas’: so the answer to your question is probably: we should re-vote #971
  103. jonas’ re-writing my email from back then, I arrive at: Let me break this change down using the word diff (attached: ab.wdiff, pipe it through colordiff(1) for best viewing). Before: - type="form": @type SHOULD, absent implies "text-single" - type="submit": @type MAY, absent assumes available context(*) - type="result": @type MAY, absent undefined - type="error": SHOULD NOT have any fields, @type MAY After: - type="form": @type SHOULD, absent implies "text-single" - type="submit", type="result": @type MAY, absent assumes available context(*) - type="error": SHOULD NOT have any fields, @type MAY (*): It is assumed that the recipient of the form has enough context to infer the @type value. Bad design IMO, but we’re stuck with that. So while the PR reduces the amount of text, it introduces undefined behaviour for @type="error", which I don’t endorse.
  104. jonas’ re-writing my email from back then, I arrive at: Let me break this change down using the word diff (attached: ab.wdiff, pipe it through colordiff(1) for best viewing). Before: - type="form": @type SHOULD, absent implies "text-single" - type="submit": @type MAY, absent assumes available context(*) - type="result": @type MAY, absent undefined - type="error": SHOULD NOT have any fields, @type undefined After: - type="form": @type SHOULD, absent implies "text-single" - type="submit", type="result": @type MAY, absent assumes available context(*) - type="error": SHOULD NOT have any fields, @type MAY (*): It is assumed that the recipient of the form has enough context to infer the @type value. Bad design IMO, but we’re stuck with that. So while the PR reduces the amount of text, it introduces undefined behaviour for @type="error", which I don’t endorse.
  105. jonas’ and I think I prefer that a lot and would also suggest to re-vote
  106. jonas’ daniel, hence wdiff + colordiff
  107. Zash + aha | htmlpaste
  108. jonas’ :)
  109. jonas’ I’m still in favour of my patch though, because that handles the case where an entity violates the SHOULD NOT for type="error" and clearly spells out what’s going on
  110. jonas’ I guess I’ll propose my patch as separate PR and then we can vote on both?
  111. daniel Sounds good
  112. Ge0rG jonas’: great
  113. Zash Sure
  114. Ge0rG and maybe Zash can provide a rendered html-diff of it ;)
  115. dwd has joined
  116. jonas’ https://github.com/xsf/xeps/pull/975
  117. dwd Gah. Afternoon, sorry for being late.
  118. jonas’ oh great, dwd
  119. jonas’ I suppose you’ll have strong opinions regarding how we should handle Process here
  120. jonas’ (and I’d really like to hear them)
  121. Zash https://cerdale.zash.se/upload/ZYq7Ie4XUavFzq0k/pr971.html
  122. Ge0rG jonas’: is there really Process for bringing up the same PR again?
  123. jonas’ Ge0rG, probably not written down, but dwd still might have a valuable opinion on that :)
  124. Ge0rG Zash: it is HTML, but it's not HTML.
  125. jonas’ Zash, those \" make it harder to read :/
  126. dwd PRs are nothing but a convenient way to give things to Council, I don';t think there's anything preventing us using the same one twice is there?
  127. Zash pandoc does that
  128. jonas’ dwd, no, it’s about re-voting on the same thing after council pretty clearly vetoed it before
  129. jonas’ Zash, can you do the diff on the xml instead of whatever pandoc did there?
  130. jonas’ I think the colour-coding would already hep
  131. jonas’ I think the colour-coding would already help
  132. dwd Ah. So there's nothing that prevents us doing so, but unless new things have come to light I feel a little concerned about doing that.
  133. jonas’ (hoping that none of us has red-green-weakness)
  134. Ge0rG dwd: new things like the realization that the first voting Member was wrong, and the other ones just copy&pasted the rationale?
  135. jonas’ dwd, I expected as much. Do you think that new things did indeed come to light based on what I wrote earlier (in the agenda announcement and above, I shall quote from above): since XEP-0004 states: > a data form of type "cancel" SHOULD NOT contain any <field/> elements. I think some of the arguments in my original email regarding this topic may be invalid since others based their vote on those arguments, please reconsider
  136. jonas’ or as Ge0rG put it, indeed
  137. Zash jonas’: Main difference is extra noise and lack of line breaks in paragraphs.
  138. Ge0rG jonas’: I really like your wording as displayed by Zash's colored "html" version
  139. jonas’ that’s not my wording tho?
  140. jonas’ that’s flows wording
  141. Zash That wasn't jonas’
  142. dwd Ge0rG, Well, there's a good argument to avoid "me too" veto votes, of course. :-)
  143. Ge0rG dwd: yes, I'm guilty of that. But the rationale that was provided really sounded convincing back then!
  144. jonas’ it’s easy to construct convincing-sounding rationales for '4, '45 and '60.
  145. jonas’ (and probably '369 et al. too)
  146. Ge0rG whoops.
  147. jonas’ though I’ll clearly state that this was not my intention and I simply wasn’t aware of the type="cancel" specialcasing
  148. Ge0rG So I really like flow's wording then. Can we also get a pr975.html, please? Zash?
  149. dwd I like the table. ISTR I was on-list because I was confused about what the wording used to say and what it now says, which at the very least suggests that the wording needs improvement.
  150. jonas’ what table are we talking about?
  151. Ge0rG the one in your mail?
  152. jonas’ I didn’t consider that to be a table
  153. jonas’ but ok
  154. dwd Bullet point list. Table. It's hot.
  155. jonas’ I agree
  156. Zash ^C^V that into the XEP and call it a day?©
  157. jonas’ I can do a PR for that, too
  158. jonas’ or maybe instead of #975
  159. jonas’ okay, either way
  160. jonas’ we’re close to the end of the meeting and everyone is confused
  161. dwd But if I understand correctly, we're happy about the intent in flow's PR, just not so much about the wording?
  162. jonas’ I am
  163. jonas’ as I said in my original email
  164. jonas’ I take that we should re-vote on PR#971 and/or PR#975 next week. Please read carefully everyone, I’ll update PR#975 with a more major reformatting after this meeting (taking the suggestion to pull my "table" from the email into the document)
  165. jonas’ 5) Date of Next
  166. Zash +1w?
  167. jonas’ +1w wfm
  168. Zash +1w wfm
  169. daniel +1w wfm
  170. Ge0rG +1W WFM
  171. Ge0rG +1w wfm
  172. Lance has left
  173. dwd +1. Having (a) moved my XMPP server to AWS off the machine that was failing, and (b) moved DNS to a machine with IPv4, I might even be able to join properly.
  174. jonas’ excellent
  175. jonas’ except the IPv4 port
  176. jonas’ except the IPv4 part
  177. jonas’ 6) AOB
  178. jonas’ (I skipped over pending votes...)
  179. jonas’ Ge0rG, wanna vote on the SASL-EXTERNAL one? it expires today.
  180. jonas’ https://github.com/xsf/xeps/pull/963
  181. Ge0rG I'm pretty sure I already +1ed SASL-EXTERNAL, but consider it being casted now.
  182. Ge0rG *cast
  183. jonas’ ok, maybe I missed it from last week
  184. jonas’ thanks
  185. Ge0rG It's hot.
  186. jonas’ any other AOB?
  187. Ge0rG I sent a mail to standards@ re MUC-PMs vs. Direct Messages
  188. jonas’ it contained several words I find highly complex and I am out of my safe operating parameters
  189. Ge0rG There was one response so far. I'd love to see more.
  190. jonas’ it contained several words I find highly complex and I am outside my safe operating parameters
  191. Ge0rG Did I curse, accidentally?
  192. dwd I would like to second Ge0rG's observation that it is hot.
  193. jonas’ Ge0rG, no, but you said nasty words like "MUC-PM", "Carbons", and "MAM"
  194. Ge0rG or are those words "RECOMMENDED" and "SHOULD NOT"?
  195. Zash Heh
  196. Ge0rG jonas’: I was just setting the stage. The mail is mostly harmless.
  197. jonas’ https://share.dreckshal.de/dpm/Ct5F9khjRIzTuqrGSBM_Nr0URuHpdsbwWdzOdWXhW48.png
  198. debacle has left
  199. jonas’ Ge0rG, thanks for the hint, I’ll take a look and see that I can reply soon-ish
  200. jonas’ if you don’t see an email from me in that thread by the end of the week, feel free to poke.
  201. Ge0rG jonas’: thanks
  202. jonas’ AO-AO-AOB?
  203. jonas’ (real quick, because we’re past the time)
  204. jonas’ no typing notification and no previous mention, taking that as a no
  205. jonas’ 7) Ite Meeting Est
  206. jonas’ Thanks everyone for appearing despite the straining weather conditions
  207. jonas’ and for participating
  208. Zash Thanks
  209. Ge0rG Thanks jonas’ and Tedd
  210. jonas’ I updated PR#975: https://github.com/xsf/xeps/pull/975
  211. Ge0rG +1
  212. marc0s has left
  213. marc0s has joined
  214. Lance has joined
  215. Zash Text looks good.
  216. Zash XML error tho
  217. jonas’ Zash, thanks, fixed
  218. Zash > the recieving entity can infer the 'type' attribute value from context often, but not allways
  219. jonas’ not my choice of wording, unfortunately
  220. Zash https://cerdale.zash.se/upload/rbYit4kCAuY1LCQu/pr971.html
  221. Zash eh, where's the diff?
  222. Zash oh, 971
  223. Zash https://cerdale.zash.se/upload/wWubXvCY6TocdW5Z/pr975.html
  224. Zash There
  225. stpeter has joined
  226. Lance has left
  227. sonny has left
  228. sonny has joined
  229. sonny has left
  230. sonny has joined
  231. Lance has joined
  232. ralphm has left
  233. paul has left
  234. paul has joined
  235. ralphm has joined
  236. sonny has left
  237. marc0s has left
  238. adiaholic_ has left
  239. adiaholic_ has joined
  240. marc0s has joined
  241. adiaholic_ has left
  242. Guus has left
  243. Guus has joined
  244. bear has left
  245. sonny has joined
  246. bear has joined
  247. sonny has left
  248. sonny has joined
  249. bear has left
  250. bear has joined
  251. stpeter has left
  252. Tobias has left
  253. stpeter has joined
  254. stpeter has left
  255. sonny has left
  256. sonny has joined
  257. stpeter has joined
  258. stpeter has left
  259. stpeter has joined
  260. eta has left
  261. eta has joined
  262. vaulor has left
  263. SouL has left
  264. stpeter has left
  265. bear has left
  266. neox has left