XMPP Council - 2020-06-17


  1. Ge0rG

    It's this time of the week again!

  2. jonas’

    quite

  3. Ge0rG

    I have a hard cut in +30m due to a company-wide corona party, so let's not stretch too much today

  4. dwd

    Mexican beer?

  5. Ge0rG

    I have no idea.

  6. jonas’

    1) Roll Call

  7. daniel

    here

  8. Ge0rG

  9. Zash

    here

  10. jonas’

    I’ve spotted a dwd already, so full house, excellent

  11. jonas’

    2) Agenda Bashing

  12. jonas’

    anything to modify?

  13. jonas’

    assuming no

  14. dwd

    Not from me.

  15. jonas’

    3) Editor’s Update - Calls in progress - LC for XEP-0338 (ends on 2020-06-30)

  16. jonas’

    4) Items for voting

  17. jonas’

    4a) PR#959: XEP-0156: reorganize stating XRD/JRD requirements URL: https://github.com/xsf/xeps/pull/959 Abstract: The reference to RFC 6120 was incorrect, what this really meant is RFC 6415. But instead of simply s/RFC 6120/RFC 6415/ here, I decided to reorganize stating the requirements of XRD and JRD a little.

  18. jonas’

    This PR was amended to address council feedback from last session and is on the table again.

  19. jonas’

    +1 on the PR now

  20. Zash

    +1

  21. jonas’

    I think it improves the wording and could even count as editorial at this point.

  22. dwd

    +1, though if we want to change the last bit to read "additionally", that'd be possibly clearer.

  23. jonas’

    oh, though, it makes JRD SHOULD instead of MAY

  24. Ge0rG

    +1

  25. jonas’

    (OPTIONAL = MAY)

  26. dwd

    Specifically, line 222 "It is possible to use an alternative JSON format..." - that always read that way but it might benefit from "additionally".

  27. daniel

    +1 on the PR

  28. dwd

    And yes, I noted that this raises JRD to a SHOULD, I assumed that was for interoperability reasons?

  29. jonas’

    I don’t think we should be nitpicking wording here on this level

  30. dwd

    jonas’, And I'm not. Just noting.

  31. jonas’

    fair

  32. jonas’

    I was tempted to reply, so I felt the need to say that instead :)

  33. jonas’

    raising the level for JRD makes sense to me in the web context, so no objections and we can move on

  34. jonas’

    4b) PR#961: XEP-0030: Specify that the disco#info feature may not be explicitly set URL: https://github.com/xsf/xeps/pull/961 Abstract: Since #715 got rejected by council, we may as well drop the requirement to specify this explicitly. See-Also: https://github.com/xsf/xeps/pull/715

  35. jonas’

    assuming my comments in the PR are addressed, I am still left to wonder what this imporoves.

  36. jonas’

    assuming my comments in the PR are addressed, I am still left to wonder what this improves.

  37. jonas’

    and I think we should set the bar for changing normative text of Final XEPs rather high.

  38. dwd

    jonas’, The problem this addresses is twofold: Firstly, it's clearly a bit weird to worry about discovering support for service discovery by first making a service discovery request to see if the response includes service discovery.

  39. jonas’

    I mean, I see that announcing disco#info is kind of pointless in a disco#info response, but I also don’t see how this fixes any real-world problem.

  40. Zash

    Sure, disco#info might be redundant to advertise. But what jonas’ said.

  41. dwd

    jonas’, Secondly, ~none of our other XEP examples include this.

  42. dwd

    jonas’, So by making this optional, it immediately means our XEPs become conformant.

  43. Zash

    dwd, examples? are not normative

  44. daniel

    is there a mailing list post or something that describes the problem that this PR is trying to address?

  45. jonas’

    I don’t see a problem with the latter. I advocated for blanket-including <!-- ... --> in disco#info examples if one is bothered by them not being complete (which I always felt to be obvious, because if every XEP had full disco#info examples we’d have much longer and more noisy texts for no gain)

  46. jonas’

    daniel, not beyond that it’s the author’s follow-up to the rejection of https://github.com/xsf/xeps/pull/715

  47. dwd

    daniel, It's trying to document reality. Seems fine by me.

  48. jonas’

    to me, it only documents reality of the examples in our documents; that it documents reality on the wire I’d like to see proven first.

  49. dwd

    That said, I'm -1 for the reasons jonas’ raiuses on the PR.

  50. dwd

    jonas’, There was lots of discussion around this. Seems most implementations proudly return disco#info, if only to ensure there's at least one feature present.

  51. Ge0rG

    I'm on-list

  52. jonas’

    -1, unless the author can find real-world issues which are solved by this PR. Specifically, if we don’t require disco#info and then stop requiring at-lesat-one element, it might break strict validators (the existence of which I could endorse given that this is a Final document and at-least-one is a MUST) for no good reason.

  53. Zash

    -1, agree with jonas’ & dwd

  54. daniel

    yes I agree with jonas’ here as well

  55. dwd

    I could go for "disco#info MAY be elided if other features are present" quite comfortably though.

  56. jonas’

    as a sidenote, I would very much prefer us being explicit about disco#info replies specifically

  57. jonas’

    as a sidenote, I would very much prefer us being explicit about disco#info replies specifically *not* being seen as complete in XEP examples, e.g. by using <!-- ... -->.

  58. Zash

    sure

  59. jonas’

    because you could turn this the other way ’round too, if you wanted to be pedantic: if '45 does not include pubsub features, is a MUC which announces them non-comformant?

  60. dwd

    jonas’, I'd be fine with that as well.

  61. dwd

    jonas’, No, you can't.

  62. jonas’

    moving on

  63. jonas’

    dwd, as devil’s advocate, I find a way to disagree, but I don’t want to waste everyone’s time on this stupid argument of mine :)

  64. jonas’

    4c) PR#949: XEP-0157: Add status-addresses registrar entry URL: https://github.com/xsf/xeps/pull/949 See-Also: https://mail.jabber.org/pipermail/standards/2020-May/037443.html See-Also: https://mail.jabber.org/pipermail/standards/2020-June/037537.html

  65. jonas’

    We also had this one a few weeks back, but there was discussion about extending the registry without consent from '68. See the second linked mailing list thread.

  66. jonas’

    Hence, the validation stuff has been removed from the PR

  67. jonas’

    Hence, the validation stuff has been removed from the PR and converted into explicit wording, which I think is a reasonable compromise.

  68. jonas’

    This would allow us to move forward with extending '68 with validation and then amend the registry entry without breaking anything.

  69. jonas’

    so +1

  70. dwd

    +1 for this. Noting my misgivings in general about how the Registrar is operating currently.

  71. Zash

    +1

  72. jonas’

    you mean, not at all? :)

  73. jonas’

    I endorse how you rejected a PR of mine to hack into the '45 registry on that grounds (to motivate me to fix the registry), but let other’s PRs pass :)

  74. jonas’

    (no offense intended, I am glad that you don’t veto this one)

  75. jonas’

    (no offense intended or taken, I am glad that you don’t veto this one)

  76. daniel

    +1

  77. dwd

    Well, in this case the additional entry related closely to the XEP it's in.

  78. jonas’

    Ge0rG, anything from you?

  79. daniel

    pregaming for the corona party?

  80. jonas’

    assuming on-list then

  81. jonas’

    (also due to lack of chat states)

  82. jonas’

    5) Outstanding Votes - daniel and Zash are pending on PR#598 (expiring next week) AFAIK (<https://github.com/xsf/xeps/pull/598>)

  83. jonas’

    other than that, just the pending ones from Ge0rG from this session

  84. jonas’

    6) Date of Next

  85. jonas’

    +1w wfm

  86. Zash

    +1w wfm

  87. jonas’

    thooough I might have a very hard cutoff that day

  88. jonas’

    and/or might find during the week that I need a replacement

  89. jonas’

    no plans yet, but it’s a date which might cause high-priority plans to appear out of nowhere

  90. Ge0rG

    +1 for 0157

  91. Ge0rG

    Sorry, got distracted

  92. pep.

    woo

  93. jonas’

    so if someone is happy to stand in as chair in case I miss the meeting, of course with a prepared agenda, that’d be good

  94. dwd

    I can be a stand-in chair.

  95. jonas’

    thank you

  96. dwd

    If a chair *can* be a stand-in.

  97. stpeter

    Please, people, it's not safe to stand in a chair.

  98. jonas’ waves to stpeter

  99. daniel

    i’m going to be on a train for the first time in forever next wednesday. but I think i'll be able to participate from my phone

  100. jonas’

    daniel, wear your mask!

  101. jonas’

    okay, we’ll see what we can manage

  102. jonas’

    I don’t expect a lot of things to pop up anyways

  103. jonas’

    7) AOB

  104. pep.

    Yeah wearing a mask is important to participate from a phone

  105. jonas’

    anyone got any?

  106. stpeter

    BTW https://github.com/xsf/xeps/pull/905 is on my radar screen, I just need to carve out time to look at it more closely.

  107. Zash

    Nah

  108. jonas’

    stpeter, excellent

  109. jonas’

    thanks for that

  110. Zash

    stpeter, while you're here, may I poke vrt vcard4? iirc it got into LC but then ???

  111. dwd

    I was wondering if we wanted to get a video call together for us, specifically *not* as a Council meeting, but as a more general chat.

  112. stpeter

    Do always feel free to poke me (hard it necessary) about PRs.

  113. jonas’

    dwd, that sounds like fun

  114. jonas’

    I hear the video call stacks around the world got a lot better in the past few months

  115. dwd

    Obviously we'll need to spend some time considering what platform to use.

  116. stpeter

    Zash: hmm, OK - as I recall, there wasn't strong interest at the time

  117. Zash

    FWIW I'll have a lot more time from next week

  118. jonas’

    dwd, please no bikeshedding on that

  119. jonas’

    if you want it to be a general chat

  120. jonas’

    if nobody objects, I’d just suggest some jitsi instance, be it the official one or the ffmuc one

  121. Ge0rG

    daniel: your optimism implies that you will be travelling abroad? ;)

  122. dwd

    Jitsi is fine by me. I'll sling some time suggestions around the Council list and see if there's interest there.

  123. stpeter

    Clearly we should create a list of all possible videoconferencing options and randomly select using the procedures in https://tools.ietf.org/html/rfc3797

  124. jonas’

    dwd, that sounds excellent, thank you

  125. jonas’

    any other AOB?

  126. stpeter

    (But seriously I'd just use Jitsi.)

  127. jonas’

    (to clarify, when I say Jitsi, I generally refer to Jitsi Meet)

  128. daniel

    Ge0rG, no. just to the other side of country

  129. jonas’

    (although I’m aware that’s incorrect)

  130. jonas’

    assuming no council-relevant AOB, so

  131. Ge0rG

    daniel: I don't think there was significant improvement of mobile network coverage in the last months ;)

  132. jonas’

    8) Ite Meeting Est

  133. jonas’

    have a splendid evening/remainder of the day everyone

  134. dwd

    Thanks jonas’!

  135. Zash

    Thanks jonas’, all

  136. Ge0rG

    thanks jonas’

  137. stpeter

    +1

  138. jonas’

    the weather here is amazing if you can repress the nagging thoughts about dryness and climate change

  139. daniel

    oh. I had honestly forgotten that this is an issue

  140. dwd

    jonas’, BTW, I was looking at Gitlab/Github mirroring; I'd not realised that Gitlab can do that automagically for you these days.

  141. jonas’

    dwd, to be honest, we’d hack that in CI jobs

  142. jonas’

    to have more control over when a mirror action happens and to have it push based and to be able to constrain the permissions

  143. Zash

    what about the locust attack in east africa?

  144. jonas’

    (using deploy keys instead of oauth permissions)

  145. Ge0rG

    speaking of which: I really liked the gitlab proposal, and I don't care much if gitlab or github is our primary venue, and I'm okay with shutting down the other one altogether after the proof-of-concept phase

  146. jonas’

    Ge0rG, thanks for the feedback

  147. jonas’

    dwd, the main issue we’re having with the gitlab migration though is the lack of the CLA bot thing... we’ll have to improvise something there, unfortunately.

  148. jonas’

    that’s really a bummer

  149. pep.

    It's curious really that there's no CLA bot

  150. pep.

    That seems to be a common thing to have CLAs (unfortunately?)

  151. jonas’

    they don’t have an "app" platform at all

  152. jonas’

    AFAIK

  153. jonas’

    so that might be why

  154. jonas’

    or it’s simply a popularity issue

  155. pep.

    maybe

  156. jonas’

    I mean there is an implementation, but you have to do AWS Lambda webscale stuff and host it yourself, which I don’t quite appreciate right now

  157. jonas’

    -> https://github.com/ScottLogic/gitlab-cla-bot/

  158. pep.

    yeah no thanks

  159. jonas’

    exactly

  160. jonas’

    I mean the API should give you enough info based on that, so maybe someone from the community wants to step up and build a thing *hinthint* *nudgenudge*

  161. jonas’

    we could do a basic "hey, we don’t know you yet" comment thing in the CI with appropriate credentials, but it’d still lack any kind of interactiveness

  162. pep.

    kinda lost when it comes to searching for this specific issue

  163. pep.

    kinda lost when it comes to searching for this specific problem

  164. pep.

    re keywords

  165. jonas’

    FTR: https://gitlab.com/gitlab-org/gitlab/-/issues/15899

  166. pep.

    If we can make CI figure out if somebody has signed we can "just" make it terminate early right? We don't actually need to have any API in issues for that I guess?

  167. pep.

    Maybe it's just a flag on the issue? dunno if we can set stuff like that

  168. jonas’

    -> editor@