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