XSF Discussion - 2019-12-03

  1. edhelas

    yes, this allows me to properly setup the popup window and negociate the jingle call after that

  2. nyco

    is our wiki down? or it is just me...

  3. nyco

    it's back...

  4. nyco

    there has been a very high delay on xmpp.org and jabber.org... for me

  5. jonas’

    yeah, it’s been flapping here, too

  6. Zash

    Oh I thought my s2s was broken just now

  7. Ge0rG

    I just had IPv6 issues, it seems

  8. nyco

    ok... hey do we have some monitoring on our infra?

  9. MattJ

    We don't

  10. nyco

    I guess we should... should we put such an item somewhere close to the top of the task list of the iTeam? I mean no harrassment

  11. MattJ

    It's somewhere below "First draw up a list of what servers and services we are running"

  12. nyco

    ok, thx :) May The Force Be With You

  13. MattJ

    Speaking of iteam, I'm updating Github permissions as we discussed in one of the recent board meetings

  14. MattJ

    Anyone who doesn't have access to something they think they ought to have access to, feel free to poke me and I'll investigate

  15. Zash

    Who should have access to what?

  16. MattJ

    The main change is that there is a (hidden, iirc) "Web" team

  17. MattJ

    which has a bunch of people in it

  18. MattJ

    All the people who are actually doing stuff are already in teams that already have access to the relevant repos

  19. MattJ

    So the goal is to simplify Github permissions so they align with XSF team membership

  20. MattJ

    which will make it easier to see and manage who has access to what

  21. MattJ

    to clarify what I wrote above - the "Web" team exists, but is being removed in favour of more well-defined teams

  22. pep.


  23. MattJ

    Link Mauve is popping up a lot

  24. MattJ

    Are you actually in any formal teams?

  25. pep.

    I don't think he is

  26. MattJ

    There is a team called "xep build" with literally just Link Mauve in it

  27. pep.


  28. pep.

    He just helps a lot

  29. pep.

    But I don't think he's got any commit rights

  30. pep.

    (or should have by the definition above)

  31. MattJ

    "xep build" has read access to xep-docker-base (but read access is already default for all org members), and write access to xsf/xeps

  32. pep.


  33. pep.

    Maybe he should "just" become an editor

  34. MattJ

    Well, as per the discussion, this team is going - and if someone tells me Link Mauve has become an editor, then he can be added to that team

  35. MattJ

    But like all MUCs, he seems to be in them all anyway somehow

  36. pep.

    MattJ, sure, let that team go :)

  37. MattJ

    Done already

  38. pep.


  39. pep.

    Link Mauve, ^ you know what you have to do now

  40. pep.

    (apply to all the teams \o/)

  41. MattJ

    We have two Github org members who don't appear to be actual XSF members (now) - Matt Miller and Sam Whited

  42. MattJ

    Both are in the Editors team on Github

  43. Kev

    The Editors team can only be members, IIRC (don't take my word for it), so I think they've naturally fallen off.

  44. MattJ


  45. MattJ

    Hmm, seems there's one more that shouldn't be there according to a count...

  46. MattJ does a mental diff

  47. MattJ

    Guus is not listed here: https://xmpp.org/about/xsf/editor-team.html

  48. Guus

    I'm not an editor

  49. MattJ

    Yet is on the Editors team on Github

  50. MattJ


  51. MattJ

    Ok, done

  52. MattJ

    Now we have two Github members without teams: Alex and Link Mauve

  53. MattJ

    Would be good to figure out what Alex needs access to

  54. pep.

    We can have a secretary team I guess if necessary. What does the secretary have to edit? xsf/xmpp.org? (I wish we could have finer grained permissions in repos)

  55. MattJ

    You can have individual permissions (in fact that's what Alex has for xmpp.org)

  56. Alex

    I usually only edit content

  57. pep.

    MattJ, yeah but if/when Alex leaves the position, then we're going to have to go through that again, whereas we could just swap people in a team ("role") otherwise

  58. Zash

    MattJ: Am I in iteam?

  59. MattJ

    Yep, I'll create a team

  60. Alex

    have plans to move memberbot to our Github org when thzere are no concerns. Lance archived it on Github https://github.com/legastero/memberbot

  61. MattJ

    Zash, in the team yes, in Github I can check

  62. Guus

    > have plans to move memberbot to our Github org when thzere are no concerns. Seems sensible

  63. pep.


  64. MattJ

    Ok, pretty much done

  65. MattJ

    There is one more team I would like to solve, there is one called "Core" that just seems to map to a handful of arbitrary trusted people

  66. MattJ

    It seems that should be replaced by org admins and/or iteam

  67. Guus

    Sounds good, MattJ

  68. pep.


  69. Guus

    I just got an email notification after being kicked out of a team

  70. Kev

    Core can probably go, I guess. Most people in there are org admins.

  71. Kev

    Owners, rather.

  72. ralphm

    With Alex being an Officer, maybe you can create a team for officers, and put Peter in it, too.

  73. pep.

    Kev, should they though

  74. Guus

    so people that are worried about loosing access have a chance to complain

  75. Kev

    Actually, all people, by the look of it?

  76. Kev

    pep.: And yes, I'd arbitrarily claim that all the people who're org owners are sensible to be org owners.

  77. MattJ

    Kev, yep, looks like all Core members are org owners... I'll remove it

  78. pep.

    Kev, I don't even know who is org owner

  79. pep.

    Ah I can see it, cool

  80. pep.

    I disagree

  81. pep.

    hmm ok intosi and stpeter are also in iteam

  82. Kev

    With the exception of Ralph, it's a subset of iteam selected by the (then-)iteam lead.

  83. jonas’

    Guus, didn’t you leave iteam?

  84. Guus

    I did

  85. MattJ

    Yeah, I'd say all Board + iteam are candidates

  86. pep.

    I was wondering

  87. Kev

    I thought Guus had removed his sudo, but was still on iteam.

  88. pep.

    MattJ, tbh I'd vote for board not to be owners, iteam is good enough

  89. Kev

    I'd be happy with it being an iteam subset, selected by the iteam lead. Same as who gets sudo on boxen.

  90. Guus

    let's not have half-members of teams - that's just complexity that we can do without 🙂

  91. Kev

    (I don't mean it's the same list of people, I mean it's the same 'iteam lead gets to make sensible iteam decisions')

  92. Kev

    Matt might reasonably disagree with me on who a sensible subset of iteam are, naturally :)

  93. ralphm

    I think the team, whatever its name (Core, Owners), is good as it is.

  94. MattJ

    It's gone :)

  95. ralphm

    or "the set of people that are owners"

  96. MattJ

    It was unnecessary and confused thing. The only thing up for debate right now is who should in the owner list of the Github org

  97. MattJ

    *confused things

  98. ralphm

    As I said, it seems fine to me like this.

  99. MattJ

    Same here, especially since I've run out of any more time to spend on this today

  100. ralphm


  101. ralphm

    Thanks for looking into it.

  102. Kev

    And, regardless, I think Matt gets to make the call.

  103. ralphm


  104. MattJ

    But now we only have Github teams that are actual XSF teams (or roles), and the only members of those teams are people who are officially members of those XSF teams

  105. ralphm

    and so does Board, by the way, as we discussed a few meetings ago

  106. Guus


  107. Kev

    Board shouldn't be interfering in iteam.

  108. ralphm


  109. nyco

    if anyone wants to engage: https://fosstodon.org/web/statuses/103243542343931019

  110. nyco

    Newsletter sent PR merged for the blog post: https://github.com/xsf/xmpp.org/pull/660

  111. nyco

    thx for the rights to merge

  112. nyco

    now should I do anything else to deploy?

  113. Zash

    Doesn't The Cloud do that automagically?

  114. pep.

    nyco, CI should take care of it

  115. nyco

    then: > now should I do anything else to deploy? 1. Wait

  116. nyco


  117. nyco

    aaaand the wait has been... long! https://xmpp.org/2019/12/newsletter-03-december/

  118. lskdjf

    ARGH! there's a article in the newsletter that advertises to install dino from snap. That's a terrible idea, the snap is 3 years old and isn't maintained 😢

  119. jonas’

    hm, my agenda announcement is stuck in the council@ queue. can someone please check which of my addresess is listed as being allowed to send to there?

  120. jonas’

    last council mail I received went to teh address I used to send the agenda

  121. Ge0rG

    jonas’: standards@ has passed through, so it's probably not too bad.

  122. Ge0rG

    jonas’: I'm most probably going to miss tomorrow

  123. Zash

    jonas’, I seem to have received it

  124. jonas’

    Zash, I sent to both standards@ and council@

  125. jonas’

    so you probably got it via standards@

  126. Zash

    Oh, yeah

  127. jonas’

    Ge0rG, noted, thanks

  128. jonas’

    Ge0rG, although it’s a pity because there seems to be plenty time for your stack of AOB

  129. Ge0rG

    jonas’: I'm unprepared and I forgot most.

  130. jonas’

    I bet we could find them in logs ;)

  131. Ge0rG

    jonas’: also apparently Council is not there to do guidance on how the standard should evolve, but merely for voting on submissions

  132. jonas’


  133. Ge0rG

    jonas’: what about calling up https://mail.jabber.org/pipermail/standards/2019-August/036332.html for discussion tomorrow, then?

  134. Zash

    Doesn't mean you can't do stuff

  135. Ge0rG

    I can't do stuff

  136. Zash

    Council status doesn't stop you

  137. Zash

    Neither does lack of council

  138. Ge0rG

    I'm blocked on my own segregation of duties issue.

  139. Dele (Mobile)

    I am doing some cleanup of old code in Openfire and wanted to get a feel of who else in the XSF community is still supporting XEP-0136: Message Archiving and older versions of XEP-0313: Message Archive Management. Is there anyone supporting an xmpp server or client that still handles the urn:xmpp:archive, urn:xmpp:mam:1 and urn:xmpp:mam:0 namespace?

  140. Zash

    Prosody only includes MAM :2 out of the box.

  141. Zash

    The there existed a community module for XEP-0136 but it was removed long ago.

  142. Holger

    ejabberd supports them all out of the box. But isn't the real question whether there are still many clients in the wild not doing :2?

  143. Ge0rG

    Holger: could you measure that on your deployment?

  144. Holger

    Well, not without touching the code …

  145. Zash

    How fast does the XMPP world move?

  146. Holger

    I would think there should be quite some incentive for client devs to go for :2 as dedup is such a PITA without stanza IDs …

  147. Holger

    But no idea about the implementation status.

  148. Dele (Mobile)

    Thanks for the quick response. I was going to remove support for xep-136 and keep only mam:2 🙂

  149. Holger

    Er yes ejabberd doesn't do 0136 anymore either. Just the older MAM versions.

  150. Holger

    I think Vacuum IM does 0136 …

  151. wurstsalat

    https://stats.jabberfr.org/d/000000002/jabberfr?orgId=1&fullscreen&panelId=39 lists client features fyi

  152. Zash

    Do clients advertise MAM tho?

  153. wurstsalat

    mam:1 and mam:2 are listed there at least

  154. Zash

    It's been 3 years.

  155. Zash

    I would imagine there be more support requests than there are if mam:1 was something people needed. There were some long ago tho.

  156. lovetox

    if you implement mam:2

  157. lovetox

    you can just announce mam:1 aswell

  158. lovetox

    its a subset

  159. lovetox

    the only difference is guaranteed stanza-id on mam:2

  160. lovetox

    dont implement 0

  161. lovetox

    because its different protocol wise

  162. edhelas

    I can run some statistics in the CAPS that I store in Movim

  163. edhelas

    But on my side I only support :1 and :2 I think