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