XMPP Council - 2019-10-25


  1. pep.

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

  2. pep.

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

  3. daniel

    2 month? What?

  4. daniel

    Council can just vote on the officially next meeting?!

  5. pep.

    Just an estimate of the mean voting period :P

  6. daniel

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

  7. jonas’

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

  8. Ge0rG

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

  9. pep.

    They were added rght when council rejected it

  10. Ge0rG

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

  11. 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.

  12. daniel

    the server will not send that?

  13. daniel

    except as the current value in a user defined configuration

  14. daniel

    or i'm missunderstanding what you mean by server set

  15. Ge0rG

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

  16. daniel

    it could be be the default of that configuration

  17. Ge0rG

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

  18. daniel

    do you know what the max_items config option does?

  19. Ge0rG

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

  20. daniel

    i'm talking about the node config

  21. daniel

    it is not being used for pagination in there

  22. daniel

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

  23. Ge0rG

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

  24. 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)

  25. daniel

    *for a user

  26. Ge0rG

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

  27. daniel

    ok.

  28. daniel

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

  29. daniel

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

  30. daniel

    because it might not be 'unlimited'

  31. Ge0rG

    yes.

  32. daniel

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

  33. Ge0rG

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

  34. daniel

    the server will not set it to 1024 or something

  35. Ge0rG

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

  36. daniel

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

  37. Ge0rG

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

  38. Ge0rG

    daniel: understood that now

  39. Ge0rG

    it was mostly my own confusion

  40. Ge0rG

    (due to my own lack of experience with pubsub)

  41. daniel

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

  42. daniel

    i'm not really sure how to fix that

  43. daniel

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

  44. Ge0rG

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

  45. Ge0rG

    daniel: those were different times, I suppose

  46. daniel

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

  47. daniel

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

  48. Ge0rG

    daniel: seems that nobody is

  49. 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

  50. daniel

    but usually you don’t have to do that

  51. daniel

    because draft xeps shouldn’t need that amount of changes

  52. Ge0rG

    yes.

  53. Ge0rG

    Except that both PubSub and MUC are full of holes.

  54. 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?

  55. Ge0rG

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

  56. flow

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

  57. flow

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

  58. flow

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

  59. Kev

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

  60. flow

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

  61. Ge0rG

    flow: the XSF hardly managed to maintain its existing infrastructure

  62. daniel

    that isn’t flow’s fault…

  63. 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

  64. Ge0rG

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

  65. daniel

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

  66. Ge0rG

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

  67. flow

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

  68. Ge0rG

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

  69. flow

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

  70. 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.

  71. daniel

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

  72. daniel

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

  73. Ge0rG

    Go Daniel!

  74. 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

  75. Ge0rG

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

  76. 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)

  77. flow

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

  78. 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?

  79. pep.

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

  80. pep.

    Or sth

  81. pep.

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

  82. pep.

    Ah that as already mentioned

  83. Ge0rG

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

  84. Ge0rG

    Except that things typically get voted on on-list

  85. pep.

    Hmm.

  86. Ge0rG

    In-council-review

  87. pep.

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

  88. pep.

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

  89. Ge0rG

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

  90. pep.

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

  91. pep.

    By pinging people and having them act on that

  92. pep.

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

  93. pep.

    Or move the venue of pending things

  94. pep.

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

  95. Ge0rG

    pep.: that sounds great!

  96. 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

  97. pep.

    Council should probably reply on the thread then

  98. pep.

    Giving feedback

  99. flow

    definetly

  100. Ge0rG

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

  101. pep.

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

  102. pep.

    Once it's picked up on the agenda