XMPP Council - 2019-10-25


  1. moparisthebest has left

  2. raspbeguy has joined

  3. Tobias has joined

  4. raspbeguy has left

  5. raspbeguy has joined

  6. guy has joined

  7. guy has left

  8. lnj has joined

  9. Zash has joined

  10. debacle has joined

  11. moparisthebest has joined

  12. sonny has joined

  13. Zash has left

  14. Zash has joined

  15. Zash has left

  16. stpeter has joined

  17. pep.

    Council missed https://github.com/xsf/xeps/pull/840 this week..

  18. pep.

    It was almost ready to go last week and now it's going to wait another 2 months

  19. daniel

    2 month? What?

  20. daniel

    Council can just vote on the officially next meeting?!

  21. pep.

    Just an estimate of the mean voting period :P

  22. undefined has left

  23. stpeter has left

  24. daniel

    But yes. Do please put it on the agenda for next week

  25. jonas’

    sorry, my week was ... challenging, otherwise I would’ve tried to keep track of the editor stuff for council

  26. Ge0rG

    pep.: I've looked into #840 prior to Council meeting, and didn't realize there were any changes since the last Council rejection

  27. pep.

    They were added rght when council rejected it

  28. Ge0rG

    Yes, I'm sorry. I actually did miss it in the github issue history

  29. Ge0rG

    I'm still missing an explanation of the semantics of max when sent by a client vs. by the server. But maybe those are logical for somebody expreienced in Pubsub.

  30. sonny has left

  31. daniel

    the server will not send that?

  32. daniel

    except as the current value in a user defined configuration

  33. daniel

    or i'm missunderstanding what you mean by server set

  34. Ge0rG

    So the value `max` is only ever set by a client, not by the server?

  35. daniel

    it could be be the default of that configuration

  36. Ge0rG

    And it means "don't delete anything from that node"?

  37. daniel

    do you know what the max_items config option does?

  38. Ge0rG

    depending on where it appears, either pagination or a storage limit

  39. daniel

    i'm talking about the node config

  40. daniel

    it is not being used for pagination in there

  41. daniel

    (there is a different max items attirbute somewhere but i'm not talking about that)

  42. Ge0rG

    yeah, it's pretty confusing to have both of them share the name ;)

  43. daniel

    anyway you can see the need for a other to set a node config max item to 'unbound', right? (bascially the opposite of max_items=1 which is used in pep)

  44. daniel

    *for a user

  45. Ge0rG

    don't get me wrong, I understand the need for this and the rationale behind not sticking to a random number.

  46. daniel

    ok.

  47. daniel

    however the problem is that despite what is set in node config the server might still set an internal max somewhere

  48. daniel

    that's why it is called 'max' and not 'unlimited' or something

  49. daniel

    because it might not be 'unlimited'

  50. Ge0rG

    yes.

  51. daniel

    however if the server has an internal max of 1024 the node config will remain at the value 'max'

  52. Ge0rG

    we also had that discussion of determining when you exceed the server-defined limit

  53. daniel

    the server will not set it to 1024 or something

  54. Ge0rG

    so that you don't silently lose your 1024th bookmark

  55. daniel

    that's why i don’t understand the question about server set

  56. Ge0rG

    daniel: I wasn't aware that this is only ever set by the client, not by the server.

  57. Ge0rG

    daniel: understood that now

  58. Ge0rG

    it was mostly my own confusion

  59. Ge0rG

    (due to my own lack of experience with pubsub)

  60. daniel

    and yes the fact that you will silently lose bookmarks is shitty

  61. daniel

    i'm not really sure how to fix that

  62. daniel

    i don’t understand why pubsub made it to draft when obvious nobody ever implemented that

  63. Ge0rG

    daniel: IIRC the proposal was to reject requests that are larger than max

  64. Ge0rG

    daniel: those were different times, I suppose

  65. daniel

    yes a boolean node config + feature for that would be nice

  66. daniel

    but i'm not that eager to fix a broken xep and beg council to accept my changes

  67. Ge0rG

    daniel: seems that nobody is

  68. daniel

    yes the process for making big changes to draft/final xeps is very cumbersome; as everything needs to be bikeshed by council and will take weeks

  69. daniel

    but usually you don’t have to do that

  70. daniel

    because draft xeps shouldn’t need that amount of changes

  71. Ge0rG

    yes.

  72. Ge0rG

    Except that both PubSub and MUC are full of holes.

  73. flow

    Given that council missed PR 840, and as much I hate XSF using github, can't we simply make the council's agenda whatever https://github.com/xsf/xeps/labels/Needs%20Council shows?

  74. Ge0rG

    flow: did you just volunteer to maintain that flag on github?

  75. flow

    Ge0rG, well it doesn't appear that maintaining the flag is the current issue

  76. flow

    but since I already do look over every PR and issue there, sure why not

  77. flow

    I'd rather maintain the XSF's gitlab instance FWIW

  78. Kev

    I suggest new Council is a great time to suggest helpful process tweaks.

  79. flow

    Isn't every council a great time to suggest helpful process tweaks? ;)

  80. Ge0rG

    flow: the XSF hardly managed to maintain its existing infrastructure

  81. daniel

    that isn’t flow’s fault…

  82. Ge0rG

    flow: I've reviewed that github list prior to the last meeting, and it contained much noise. As written above, I simply overlooked the fact that there was another patch added after the last Council discussion

  83. Ge0rG

    daniel: no, but adding more infra that needs to be maintained isn't going to improve the situation

  84. daniel

    noise in this context was stuff council is to lazy to deal with?

  85. Ge0rG

    daniel: things that I perceived as "were addressed / voted on by council but still have the flag set"

  86. flow

    I suggest that council simply removes the flag once council decides that it is addressed or no longer in the responsiblitiy of council

  87. Ge0rG

    I suppose that council expects editors to read up in the council minutes what was decided and act accordingly.

  88. flow

    Even then I would suggest that council simply removes the label(/flag) and ideally leaves a short comment too

  89. Ge0rG

    Council is not a person. Somebody from council would have to stand up as a volunteer, obtain the required github permissions and do that after each meeting.

  90. daniel

    Yes removing the flag, leave a comment and when accepted re-delegating that back to Editor seems like a good idea

  91. daniel

    When I get onto the next council I'll happily do that. It's not that much work. #VoteDaniel

  92. Ge0rG

    Go Daniel!

  93. flow

    Ge0rG, why after the meeting? I'd probably do it during the meeting, and ideally it is done by the current chair of the meeting

  94. Ge0rG

    flow: the chair of the meeting should be busy chairing the meeting

  95. Ge0rG

    flow: also that would require all council members to have editor permissions (not saying this is a bad thing, just that it's not done yet)

  96. flow

    Maybe not editor permissions and maybe not require all council members to hold them (but would be preferable)

  97. pep.

    > Ge0rG> things that I perceived as "were addressed / voted on by council but still have the flag set" Can we get council to add a label then when it's dealt with?

  98. pep.

    "Got council feedback", and remove the "Needs council"

  99. pep.

    Or sth

  100. pep.

    And then the author of the PR would update it and readd that label

  101. pep.

    Ah that as already mentioned

  102. Ge0rG

    pep.: Council-Accepted and Council-Rejected plus a link to minutes / log / whatever?

  103. Ge0rG

    Except that things typically get voted on on-list

  104. pep.

    Hmm.

  105. Ge0rG

    In-council-review

  106. debacle has left

  107. pep.

    Ge0rG: then you have to trust the Needs Council label, if you want to push that or editors

  108. pep.

    I don't especially want to make the whole thing even more rigid, I just want to make it clearer

  109. Ge0rG

    pep.: I don't know what I want. It just seems that currently, that label is not actually well applied

  110. pep.

    I'm trying to cleanup the mess that is /xeps/pulls

  111. pep.

    By pinging people and having them act on that

  112. pep.

    Otherwise I think I'm going to start pushing to close stuff.

  113. pep.

    Or move the venue of pending things

  114. pep.

    So that /pulls/ can effectively be used as an agenda

  115. Ge0rG

    pep.: that sounds great!

  116. flow

    The labels should tell one who is resonsible "Needs Council", "Needs Editor", and potentially what the next steps are "Ready to Merge", if it got accepted or rejected should potentially go simply in a comment

  117. pep.

    Council should probably reply on the thread then

  118. pep.

    Giving feedback

  119. flow

    definetly

  120. Ge0rG

    pep.: what should happen between the PR being discussed in council and all votes arriving?

  121. pep.

    I'm happy with a in-council-review as you said

  122. pep.

    Once it's picked up on the agenda

  123. Zash has joined

  124. sonny has joined

  125. undefined has joined

  126. Zash has left

  127. sonny has left

  128. lnj has left

  129. debacle has joined

  130. daniel has left

  131. daniel has joined

  132. moparisthebest has left

  133. Zash has joined

  134. Zash has left

  135. Zash has joined

  136. Tobias has left

  137. Zash has left