XMPP Council - 2021-02-17


  1. SouL has left
  2. neox has left
  3. stpeter has left
  4. stpeter has joined
  5. stpeter has left
  6. faith113 has joined
  7. faith113 has left
  8. paul has left
  9. Kev has left
  10. Kev has joined
  11. vaulor has joined
  12. Zash has left
  13. SouL has joined
  14. daniel has left
  15. daniel has joined
  16. Zash has joined
  17. paul has joined
  18. Tobias has joined
  19. Tobias has left
  20. Tobias has joined
  21. neox has joined
  22. Wojtek has joined
  23. debacle has joined
  24. mdosch has left
  25. mdosch has joined
  26. Zash has left
  27. adiaholic has left
  28. Zash has joined
  29. adiaholic has joined
  30. B has left
  31. B has joined
  32. SouL has left
  33. larma has left
  34. SouL has joined
  35. stpeter has joined
  36. Anas has joined
  37. Anas has left
  38. stpeter has left
  39. stpeter has joined
  40. B has left
  41. mdosch has left
  42. mdosch has joined
  43. B has joined
  44. stpeter has left
  45. aosan has joined
  46. stpeter has joined
  47. larma has joined
  48. stpeter has left
  49. aosan has left
  50. aosan has joined
  51. larma has left
  52. aosan has left
  53. aosan has joined
  54. aosan has left
  55. Sam has joined
  56. pep. has left
  57. jonas’ 1) Roll Call
  58. daniel Hi
  59. Ge0rG Hi
  60. Zash Hello
  61. Zash dwd?
  62. jonas’ let’s start
  63. jonas’ 2) Agenda Bashing
  64. jonas’ assuming no complaints
  65. jonas’ 3) Editor’s Update
  66. jonas’ nothing to report
  67. jonas’ 4) Items for voting
  68. jonas’ none that I know of, did I miss anything?
  69. dwd Oh, sorry, didn't notice.
  70. dwd Are we up to date with the data forms PR?
  71. Zash That's expiring .. now, right?
  72. jonas’ yes it is
  73. jonas’ what do you mean by "up to date"?
  74. dwd Have any of us voted?
  75. jonas’ I did
  76. jonas’ nobody else AFAIK
  77. jonas’ (I voted -0 yesterday on-list)
  78. Zash There seems to be ongoing on-list discussions.
  79. dwd In that case, I'll vote +1. As far as I can tell, doing otherwise will break several implementations including anythign based on Smack.
  80. jonas’ dwd, as-is or with s/MUST/SHOULD/?
  81. dwd jonas’, Personally I'll go with as-is. I think this is the original intent, and early implementations appear to follow it.
  82. jonas’ OK
  83. jonas’ FTR, what Drew describes on-list is exactly the behaviour of aioxmpp on the client side.
  84. dwd jonas’, I do appreciate others may disagree.
  85. jonas’ we need at least two more +1s anyway
  86. dwd jonas’, FTR, if you're consuming that way it doesn't matter. Producing, it matters more. Forwarding, though and this seems flat-out wrong.
  87. Ge0rG there was a really long thread that I didn't catch up yet :(
  88. jonas’ dwd, aioxmpp may very well produce forms, and that’s what I’m talking about here
  89. jonas’ dwd, agreed though that forwarding shouldn’t touch such things and that the implementation of them has serious issues.
  90. Kev I don’t think breaking Smack is a motivation to do things, but I think creating the headers after the content is probably broken.
  91. daniel I see why it is desirable to have it come first. I don't see how the existing text has always intended to do this
  92. Zash The thread looks to me as if it has rough consensus in the +1 direction, so I'll vote +1.
  93. Kev And a forwarding entity that changes order is certainly somewhere between ‘broken’ and ‘I hope it’s a closed deployment where they understand what they’re doing’.
  94. jonas’ daniel, agreed, too
  95. Kev daniel: Indeed, it seems like the Right Thing, it doesn’t look like the original text necessarily mandated it, but it’s fairly clear it was the intention.
  96. Kev Doesn’t it say something like “the data following the headers” or somesuch?
  97. aosan has joined
  98. Wojtek has left
  99. Ge0rG so we decide that it's okay to break implementations that don't follow that?
  100. dwd Kev, Yeah. I think it's not very clear, but the intent is there.
  101. Wojtek has joined
  102. dwd Ge0rG, Or else we decide its OK to break implementations that rely on it.
  103. Ge0rG dwd: right. but those implementations didn't have a written right to rely on it.
  104. jonas’ so I’m really reluctant about the MUST because this is Final
  105. Ge0rG only a vague implication
  106. jonas’ if it was Draft or Experimental, I’d say go with it
  107. Ge0rG still, I'm okay with making the vague implication a formal requirement
  108. jonas’ and yeah, I did not read the text as "the order on the wire must be that" either, so it’s at least ambiguous
  109. daniel > if it was Draft or Experimental, I’d say go with it Yes. (obviously)
  110. Ge0rG what about adding a note about earlier versions of the XEP not strictly mandating order?
  111. jonas’ but as this is Final… I think it needs more than just adding a MUST. I think this should have a good rationale and explanation of the change *inside the text*.
  112. Wojtek has left
  113. jonas’ Ge0rG, yes, that
  114. dwd I'd also be OK with a SHOULD. That would still mean aioxmpp and ejabberd needed a bugfix though, so it's somewhat moot.
  115. Wojtek has joined
  116. dwd Ge0rG, Or at least, "Many implementations have in the past not strictly enforced this ordering. Implementations are therefore encouraged to be flexible about the rodering"
  117. Ge0rG so -1 for the MUST as-is, +1 for either MUST with an explanatory textbox, or +1 for SHOULD
  118. jonas’ Ge0rG, would you be so kind to provide that text box?
  119. larma has joined
  120. Ge0rG "rodering" is a nice word.
  121. jonas’ the editor normally would but they’re short(er than usual) on time currently
  122. dwd Ge0rG, My language, I can do what i want with it.
  123. daniel I think I can get on board with a should
  124. Zash sgtm
  125. daniel I mean after all it's not probably not that big of a deal either way in practice. (somebody jusz needs to fix their code)
  126. jonas’ SHOULD + textbox?
  127. dwd daniel, Noting that SHOULD is not the same as MUST (BUT NOT REALLY), why is SHOULD OK here?
  128. jonas’ I have the file open now… I’ll just make a patch
  129. daniel But should feels less bad when changing a final xep
  130. Kev “Many implementations”? :D
  131. Ge0rG > Older revisions of this XEP (before 2.11.1) did not contain an explicit requirement for the ordering between <reported> and <item>. Implementations are therefore encouraged to be flexible when processing incoming data.
  132. daniel dwd: feelings
  133. Ge0rG jonas’: ^
  134. aosan has left
  135. Ge0rG but given that the PR explicitly speaks about the "XML document", and we have an XML stream, and it's not clear whether those are meant to be the same, I would expect that once I receive an <item> on the stream, NO MORE <reported> ARE EVER ALLOWED AGAIN!1!1!
  136. dwd Kev, It's not clear to me how many implementations are actually affected on either side. But it's non-zero for both.
  137. jonas’ proposed diff: https://paste.debian.net/hidden/7826dc53/
  138. jonas’ oh, what Ge0rG said seems more reasonable
  139. jonas’ updated patch: https://paste.debian.net/hidden/1749f7e9/
  140. dwd Either way, if we adding this, we should bounce it back to the list.
  141. jonas’ should we?
  142. jonas’ I consider the addition of the box editorial.
  143. Ge0rG jonas’: +1 for your diff
  144. dwd jonas’, Well, Editorial means we don't get to vote on it, not that the community shouldn't have an opportunity for feedback.
  145. jonas’ updated: https://paste.debian.net/hidden/a8de2ed3/ (s#data#&lt;x/&gt;# to make it unambiguous)
  146. daniel > updated patch: https://paste.debian.net/hidden/1749f7e9/ +1
  147. Kev Do you mean the styling of a box around some text? That seems editorial. Adding some text about implementations and encouraging behaviour definitely isn’t :)
  148. jonas’ dwd, ok, if you strongly feel so, we shall do that. I don’t see the necessity, given that the list wouldn’t have discussed this diff in the first place if we hadn’t brought it up anyway
  149. dwd jonas’, Well, that's a problem in itself, really, isn't it? :-)
  150. jonas’ dwd, ok, let’s not open this can of worms. I’ll push my diff into flows branch (if I am allowed to, we’ll see) and bounce it back to the list then.
  151. dwd jonas’, (And I was going to open that can of worms in AOB actually).
  152. Zash I don't think I can handle any cans of worms today.
  153. jonas’ I pushed a patch onto https://github.com/xsf/xeps/pull/1032, will write the mail asynchronously.
  154. jonas’ we’ll thus "cancel" the vote and re-vote on the updated diff next week after list feedback?
  155. dwd +1
  156. jonas’ (we don’t technically have to cancel, I’ll just -1 and we vote on the new diff)
  157. Zash +1
  158. jonas’ -1 because the new diff looks better considering the current state of the world
  159. jonas’ alright
  160. jonas’ IWE is pretty much vetoed, so we can move on to the other formalities and AOB
  161. jonas’ 5) Pending Votes
  162. jonas’ we did that already pretty umch
  163. jonas’ 6) Date of Next
  164. jonas’ +1w wfm
  165. daniel +1w wfm
  166. Zash +1w wfm
  167. dwd +1wwfm
  168. Zash and Ge0rG?
  169. jonas’ excellent
  170. jonas’ that’s a quorum :)
  171. jonas’ (mail sent)
  172. jonas’ 7) AOB
  173. jonas’ I hear dwd has any
  174. jonas’ I hear dwd has some
  175. dwd Just noting that the Data Forms discussion on list was very useful, but really only started once voting had begun, which feels pretty awkward - it'd be better to get these things discussed on the list first, and put on our agenda once they're "pre-discussed" so we can just vote.
  176. aosan has joined
  177. jonas’ mmmhm
  178. jonas’ I agree
  179. dwd I mean, especially when tweaking a Final spec, we seem to start list discussions a lot, and it feels like we're kind of starting the process at the wrong end.
  180. dwd (And ending up starting the clock a lot earlier than seems useful)
  181. jonas’ it would be good if a few people who are interested in messing with CI infrastructures, webhooks and the likes would get on a sprint and improve the editor pipelines around such things.
  182. daniel Can or should we make standards subscribe to github PRs
  183. daniel Or something
  184. jonas’ daniel, no.
  185. jonas’ not without pre-filtering by the Editor
  186. jonas’ (my opinion on that matter as a standards@ reader and editor)
  187. jonas’ it would be nice if things which are tagged Needs List Discussion / Needs Council got annoucned automatically though
  188. jonas’ I currently don’t have the capacities to work on that
  189. dwd Well, we could. Or we could simply tell Standards that things don't get onto the Council agenda unless someone asks for it on-list and therefore starts that discussion.
  190. jonas’ dwd, that’s an interesting way to put it
  191. Zash Subverting the Github flow? I approve
  192. jonas’ I can’t see any significant issue with that
  193. jonas’ it would be nicer to automate things further so that people don’t have to do it and to e.g. auto-include links to the diff and maybe a rendered version (if/when we can have such things), but as a first iteration, I like dwds proposal.
  194. dwd It pushes workload onto the submitter of changes a bit, but encourages them to add a bit of rationale and bring people on side, too, so I feel it's mostly win.
  195. daniel I'm also somewhat fine with the current flow. Council gets to decide on easier, non controversial things and refers back to list as soon as we encounter something that demands more discussion
  196. daniel > It pushes workload onto the submitter of changes a bit, but encourages them to add a bit of rationale and bring people on side, too, so I feel it's mostly win. But yes that's also fine with me
  197. dwd daniel, Yes but it also forces us to arbitrate what is actually controversial in the first place, which seems suboptimal, espeically when we don't have an appeals process as such.
  198. aosan has left
  199. Kev If I say it, it’s not controversial. Anyone who disagrees is themselves trying to be controversial.
  200. dwd daniel, Gets fairly messy if it's one of us that makes a PR and convinces the rest of it's uncontroversial.
  201. jonas’ Email proposal: Dear list, hat := council; The recent discussion about a change proposal on a Final spec has brought something to our attention which we think is a problem in our process. Specifically, the discussion about the change happened in the broader community only after the Council has started its voting process. If Council had been unanimous about the change, the change would’ve been applied immediately. In order to avoid lack of community participation in the future, the following change in our process is hereby established: Change proposals to XEPs which are under the control of Council do not get put on the Council agenda before there has been a thread on the standards mailing list. The thread is not required to have reactions or replies, but must be at least 48 hours old at the time the council session starts in order to be considered for voting. I hope you can see how this may improve the discussion culture and the process in general. If you have any questions or concerns, please raise them in reply to this email. We are happy to adapt this change if there are issues with it. kind regards, Jonas Schäfer (Council Chair)
  202. jonas’ I don’t like the arbitration we have to do about whether something is controversial either, so I’d like to pilot this ASAP.
  203. dwd I'm not sure I like that choice of assignment operator, but otherwise it's all good. :-)
  204. jonas’ :>
  205. Zash Sounds good
  206. jonas’ Dear list, <hat role="council"> The recent discussion about a change proposal on a Final spec has brought something to our attention which we think is a problem in our process. Specifically, the discussion about the change happened in the broader community only after the Council had started its voting process. If Council had been unanimous about the change, the change would’ve been applied immediately. In order to avoid lack of community participation in the future, the following change in our process is hereby established: Change proposals to XEPs which are under the control of Council do not get put on the Council agenda before there has been a thread on the standards mailing list. The thread is not required to have reactions or replies, but must be at least 48 hours old at the time the council session starts in order to be considered for voting. I hope you can see how this may improve the discussion culture and the process in general. If you have any questions or concerns, please raise them in reply to this email. We are happy to adapt this change if there are issues with it. </hat> kind regards, Jonas Schäfer (Council Chair)
  207. jonas’ dwd, is that better?
  208. Zash UNCLOSED TAG!!!!!
  209. jonas’ Zash, not true!
  210. Zash oh
  211. Sam No root node, not a valid document.
  212. jonas’ Sam, shush!
  213. dwd Heh. I read that as "<rat hole=...>" and thought it was very fitting. :-)
  214. Sam Maybe it's HTML.
  215. jonas’ I’ll take a quick peek at the cake in the oven and hope that any other negative feedback is raised until I return, otherwise I’ll send that as-is after the session.
  216. dwd I'm not sure if it's Council Chair or Editor you want, mind, but seeing as you're both...
  217. Sam (jokes aside, I forget why I popped in today, but this is an interesting discussion and seems like a good idea, thanks all)
  218. jonas’ dwd, yeah, I’m confused about that, too
  219. dwd (I mean, which role places things on the agenda officially?)
  220. jonas’ dwd, the chair compiles the agenda
  221. jonas’ I think
  222. jonas’ but I don’t know
  223. dwd Nor will anyone else, so we're fine.
  224. jonas’ I think so, too
  225. jonas’ any other AOB?
  226. daniel None here
  227. Kev The Chair assembles the agendums. Definitely ;)
  228. jonas’ alright
  229. jonas’ 8) Ite Meeting Est
  230. Zash Thanks jonas’, Tedd, all.
  231. dwd jonas’, Thanks, and sorry for my contributions to the overrun!
  232. jonas’ thanks everyone, thanks dwd for that neat idea, thanks Tedd for the excellent minutes of the last session
  233. jonas’ dwd, no worries!
  234. jonas’ (from my side anyway)
  235. Kev Uhm.
  236. Kev I don’t think “Dear list,” is a valid XML preamble.
  237. jonas’ Kev, Sam brought that up already, you’re late to the party
  238. jonas’ :P
  239. Kev He can’t have.
  240. Sam Needs a mime type or something. Must be HTML, but autodetection is likely to lead to errors.
  241. Kev Because the mail only just arrived, and it’s the mail to standards that starts the discussion.
  242. Kev For Sam to have already raised it he’d have had to do so in the Council meeting, and that would mean the discussion in Council was before the mailing list thread, which isn’t how we do things.
  243. jonas’ I’ll just step out of this for a while now
  244. Sam *facepalm* I was too fast.
  245. aosan has joined
  246. aosan has left
  247. aosan has joined
  248. aosan has left
  249. aosan has joined
  250. aosan has left
  251. aosan has joined
  252. daniel has left
  253. aosan has left
  254. aosan has joined
  255. daniel has joined
  256. daniel has left
  257. daniel has joined
  258. daniel has left
  259. daniel has joined
  260. adiaholic has left
  261. daniel has left
  262. daniel has joined
  263. adiaholic has joined
  264. daniel has left
  265. daniel has joined
  266. daniel has left
  267. daniel has joined
  268. sonny has left
  269. sonny has joined
  270. daniel has left
  271. daniel has joined
  272. daniel has left
  273. daniel has joined
  274. aosan has left
  275. daniel has left
  276. daniel has joined
  277. adiaholic has left
  278. adiaholic has joined
  279. aosan has joined
  280. aosan has left
  281. adiaholic has left
  282. stpeter has joined
  283. Tobias has left
  284. adiaholic has joined
  285. B has left
  286. B has joined
  287. Zash has left
  288. stpeter has left
  289. debacle has left