XSF logo XMPP Council - 2014-02-05


  1. tato has joined
  2. tato has left
  3. Tobias has left
  4. Tobias has left
  5. Tobias has joined
  6. Tobias has left
  7. Neustradamus has left
  8. Neustradamus has joined
  9. jabberjocke has left
  10. Neustradamus has joined
  11. Tobias has left
  12. Tobias has joined
  13. jabberjocke has joined
  14. jabberjocke has left
  15. ralphm has joined
  16. Tobias anything on the agenda for today?
  17. fippo i have "talk about deprecating the compliance suite" on my list and _think_ i poked kev about adding it to the agenda
  18. Tobias okay...sounds reasonable
  19. Zash has joined
  20. ralphm has left
  21. Kev You did.
  22. Lance has joined
  23. Kev It's time.
  24. Kev 1)
  25. Kev I'm here.
  26. fippo here
  27. Tobias here+
  28. Lance here
  29. Kev Matt sends apologies.
  30. Kev 2) Compliance suites.
  31. Kev Should we be deprecating 270?
  32. fippo i'd say yes because it requires 3920 and 3921. which are obsoleted by 6120 and 6121
  33. ralphm Yes
  34. Lance yes
  35. Tobias yes
  36. Kev ralphm: Don't you try and sneak your filthy votes in :p
  37. Kev And yes, I agree.
  38. fippo the more tricky question is how we replace it. we have http://xmpp.org/extensions/xep-0302.html (comp suites 2012)
  39. Kev What about 305, or whatever the replacement was?
  40. Kev 302, OK :)
  41. fippo 302 is a better starting point at least. my feeling is that we need something along the lines of "if you're a mobile client, then you should implement..."
  42. Lance yes, I'd be +1 to getting 302 active when we deprecate 270
  43. ralphm Kev: heh
  44. Tobias fippo, mobile client column?
  45. fippo "if you're a web client then...", "if you're a jingle client..."
  46. fippo tobias: more like different tables
  47. Tobias if we're improving 302 we should at least change its name
  48. ralphm no kidding
  49. Kev I think that would be sane.
  50. stpeter has joined
  51. ralphm I'm wondering if a year is a good differentiator, but don't have a better idea
  52. ralphm You'd not moving targets
  53. ralphm want
  54. stpeter why not remove the year?
  55. Kev stpeter: Because then you have to target versions, or XEP numbers.
  56. fippo well, if someone prints a flyer, they want a stable reference
  57. stpeter just "XMPP Compliance Suites"
  58. stpeter Kev: right, but we can reference the XEP number I think
  59. Kev We could do XMPP Compliance Suite and obsolete the old one and publish a new one with the same name every time, but that seems icky somehow.
  60. Lance In future, I'd say a better approach would be to make xmpp.org/extensions be able to display XEPs by use-case category
  61. stpeter "XEP-0302 compliant"
  62. ralphm you'd want to refer to a specific one? The document version?
  63. Kev It seems to me, without much consideration, that it's not a bad thing in 2014 to say you're compliant with the 2012 compliance suite.
  64. stpeter the alternative is that we commit to updating them every year :-)
  65. Tobias Lance, nice idea
  66. stpeter Kev: hmm, you're probaby right
  67. Kev It gives people a feeling how current the document is.
  68. stpeter (and then we update it whenever we think that's needed)
  69. Kev I don't feel so strongly about this that I'll fight rough consensus.
  70. Kev stpeter: By 'update' you mean 'publish a new year's'?
  71. stpeter yes
  72. Kev This seems sanest to me.
  73. ralphm Does it? If something doesn't change, is it stale?
  74. Kev ralphm: No, and I don't think that is implied.
  75. stpeter if we decide that 2012 is out of date, we start work on a new one to supersed the old
  76. Tobias Kev, and old ones get deprecated if new ones reach draft?
  77. ralphm Right
  78. Kev ralphm: But it gives someone in 2014 who doesn't support the 2014 profile yet a bit of a get-out as to why they still support 2012 only.
  79. ralphm hm
  80. Zash Perhaps drop the year and just replace the xep with a new one?
  81. ralphm ok
  82. ralphm I'd include the year then
  83. Kev Zash: That was suggested, and I prefer keeping the year, really. I don't see a strong argument against the year, other than it might make us look inactive if we skip a year - but I don't really believe that's true, either.
  84. stpeter nods to Kev
  85. Zash Mmm
  86. Kev We're not committing to providing a new suite every year, we're committing to saying that every time we think there's a change in the baseline required for XMPP, we'll release a new one and date it.
  87. Lance Kev: +1 on that statement
  88. ralphm yeah
  89. stpeter then we just need some text that says "this is the latest compliance suite and it will be replaced by a new one when the need arises"
  90. Tobias yup...with a year it's also nicer to reference....as been said, without it you'd need to refer to the version all the time (the year would be some kind of higher version)
  91. Kev stpeter: This seems entirely reasonable to me.
  92. ralphm Not +1, because Kev gets confused, but I agree
  93. Tobias stpeter, +1 for some text like that
  94. Kev ralphm: Very kind, sir.
  95. fippo '+1 as well. i dont even think we need to immediately deprecate an old suite. only when it gets obsolete for some reason (as happened to the 2010)
  96. Kev fippo: Well, there's multiple states here we could use.
  97. Kev And, it's a bit of a shame that we always go through Deprecated to get to Obsolete.
  98. Kev Because for compliance suites we probably want to go straight to Obsolete.
  99. Zash Why are they Standards Track?
  100. Tobias Kev, to change that process we'd need to change some icky ascii art, right? :)
  101. ralphm you don't have to imo
  102. Kev There's no problem with implementing an old compliance suite, so they're not logically deprecated, but they are obsolete :)
  103. fippo no. e.g. the 2012 ones would be deprecated by 2014 whereas the 2010 ones should be obsoleted
  104. Kev fippo: I don't think that releasing 2014 means there's anything actively wrong with 2012, which is what deprecated means.
  105. ralphm If Council decides it goes to Deprecated and immediately to Obsolete, that's fine
  106. Kev Deprecated means Do Not Do This.
  107. fippo kev: good point.
  108. Kev Obsolete means This Is Not Relevant Any More.
  109. ralphm The old one will be marked as superseded, obsolete seems proper
  110. ralphm We should maybe make that explicit in the red heading
  111. fippo speaking of which, didn't we discuss that heading a while back...?
  112. Kev fippo: We did.
  113. Kev Does everyone think we're done with compliance suites for the moment.
  114. Kev ?
  115. ralphm yes previous council did
  116. Lance If we need to, we should update XEP-1 to make this route OK. I know we've gone straight to obsolete before though, for roster versioning xep, etc
  117. ralphm I don't see a reason to change XEP-0001
  118. Kev A Standards Track XEP that has been advanced to a status of Final may be superseded by a future XEP approved by the XMPP Council. In such cases, the status of the earlier XEP shall be changed to Deprecated, possibly with an expiration date assigned by the XMPP Council (see the Expiration Dates section below). After a reasonable period of time or upon the passing of the expiration date, the status of the XEP shall be changed to Obsolete.
  119. ralphm just vote to do two steps at once
  120. Kev So if we feel that the reasonable period of time is measured in nanoseconds, we're golden.
  121. Lance awesome :)
  122. stpeter :)
  123. Tobias :D
  124. ralphm this!
  125. Kev I think we're done on compliance suites. Including that we have voted to Obsolete 270?
  126. Lance +1
  127. Tobias +1
  128. fippo '+1
  129. ralphm +1
  130. Kev Fabtastic.
  131. ralphm (oops, did it again)
  132. Tobias he did it again
  133. Zash Haha
  134. Kev 3) Date of next. SBTSBC?
  135. ralphm old habits die hard
  136. Lance +1
  137. Tobias wfm
  138. fippo wfm too
  139. Kev Jolly good.
  140. Kev 4) AOB?
  141. stpeter did the Council vote on XEP-0152?
  142. stpeter the last call ended on January 31
  143. stpeter notes that he needs to get the Editorial Team up and running so that things don't fall through the cracks quite as often
  144. Kev Nope. I think perhaps with the new Editor team we should formalise whether they're going to keep track of LCs or Council is.
  145. Kev My vote is, of course, that they track them and poke Council to vote on them.
  146. ralphm Council IMO
  147. stpeter Kev: I'm fine with that -- the team can request agenda items
  148. Kev I note that at the summit I asked a room full of XSF members to raise their hand if they were not volunteering for the Editor team, and no-one did. So every XSF member present who isn't already on Board or Council has volunteered to join that team :)
  149. ralphm hehe
  150. Kev I'm not quite sure why people then started calling me Evil Kev.
  151. Tobias *phew* ;)
  152. stpeter Kev: we could all learn from your management style :-)
  153. ralphm we had sufficient applications, I think
  154. Kev ralphm: Yes, I think so.
  155. stpeter ralphm: yes, I will schedule an organizational meeting next week
  156. Kev I /think/ that we decided that Council would then select from that pool, but I should check.
  157. stpeter that's my recollection
  158. stpeter we need to get the UPnP liaison team going, too
  159. Kev (I anticipate Council's selection being "You want to do it, good [man|woman|other]".
  160. Kev Yes, I have a TODO to chat to you.
  161. stpeter ok
  162. Kev I think we've not got AOB, but we do have 152 for the agenda next week.
  163. stpeter sounds good
  164. fippo evil kev: does tobias get to "vote" on the resolution we made at the non-official impromptu meeting on wednesday evening?
  165. Kev fippo: I think simple majority works there.
  166. Kev Anyway.
  167. Kev Thanks all, I think we're done.
  168. Kev bangs the gavel.
  169. ralphm Thanks!
  170. Tobias thanks
  171. Kev (The informal Council vote in question was "Should Council decide to be evil?" it passed with 4/5 of Council present :))
  172. Tobias 4/5 votes yes, let's be evil or no?
  173. stpeter tries to figure out why he can log into his personal server with Gajim but not Adium
  174. Tobias stpeter, just blame xnyhps :)
  175. ralphm :-)
  176. stpeter well, Adium would connect yesterday, but not today :-)
  177. Tobias maybe an easteregg
  178. stpeter I suppose I ought to join the xsf@ chatroom, eh?
  179. Zash stpeter: Security feature?
  180. ralphm stpeter: yes please
  181. ralphm Board meeting in a few minutes
  182. stpeter has left
  183. Lance has left
  184. Tobias has left
  185. Lance has joined
  186. Lance has left
  187. Tobias has joined
  188. winfried has joined
  189. winfried has left
  190. Tobias has left
  191. Tobias has left
  192. bear has joined
  193. Tobias has left
  194. Tobias has joined
  195. Lance has left
  196. Neustradamus has joined
  197. Lance has joined
  198. Zash has left
  199. Neustradamus has joined
  200. Tobias has left