pep.Council missed https://github.com/xsf/xeps/pull/840 this week..
pep.It was almost ready to go last week and now it's going to wait another 2 months
daniel2 month? What?
danielCouncil can just vote on the officially next meeting?!
pep.Just an estimate of the mean voting period :P
undefinedhas left
stpeterhas left
danielBut yes. Do please put it on the agenda for next week
jonas’sorry, my week was ... challenging, otherwise I would’ve tried to keep track of the editor stuff for council
Ge0rGpep.: I've looked into #840 prior to Council meeting, and didn't realize there were any changes since the last Council rejection
pep.They were added rght when council rejected it
Ge0rGYes, I'm sorry. I actually did miss it in the github issue history
Ge0rGI'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.
sonnyhas left
danielthe server will not send that?
danielexcept as the current value in a user defined configuration
danielor i'm missunderstanding what you mean by server set
Ge0rGSo the value `max` is only ever set by a client, not by the server?
danielit could be be the default of that configuration
Ge0rGAnd it means "don't delete anything from that node"?
danieldo you know what the max_items config option does?
Ge0rGdepending on where it appears, either pagination or a storage limit
danieli'm talking about the node config
danielit is not being used for pagination in there
daniel(there is a different max items attirbute somewhere but i'm not talking about that)
Ge0rGyeah, it's pretty confusing to have both of them share the name ;)
danielanyway 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)
daniel*for a user
Ge0rGdon't get me wrong, I understand the need for this and the rationale behind not sticking to a random number.
danielok.
danielhowever the problem is that despite what is set in node config the server might still set an internal max somewhere
danielthat's why it is called 'max' and not 'unlimited' or something
danielbecause it might not be 'unlimited'
Ge0rGyes.
danielhowever if the server has an internal max of 1024 the node config will remain at the value 'max'
Ge0rGwe also had that discussion of determining when you exceed the server-defined limit
danielthe server will not set it to 1024 or something
Ge0rGso that you don't silently lose your 1024th bookmark
danielthat's why i don’t understand the question about server set
Ge0rGdaniel: I wasn't aware that this is only ever set by the client, not by the server.
Ge0rGdaniel: understood that now
Ge0rGit was mostly my own confusion
Ge0rG(due to my own lack of experience with pubsub)
danieland yes the fact that you will silently lose bookmarks is shitty
danieli'm not really sure how to fix that
danieli don’t understand why pubsub made it to draft when obvious nobody ever implemented that
Ge0rGdaniel: IIRC the proposal was to reject requests that are larger than max
Ge0rGdaniel: those were different times, I suppose
danielyes a boolean node config + feature for that would be nice
danielbut i'm not that eager to fix a broken xep and beg council to accept my changes
Ge0rGdaniel: seems that nobody is
danielyes 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
danielbut usually you don’t have to do that
danielbecause draft xeps shouldn’t need that amount of changes
Ge0rGyes.
Ge0rGExcept that both PubSub and MUC are full of holes.
flowGiven 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?
Ge0rGflow: did you just volunteer to maintain that flag on github?
flowGe0rG, well it doesn't appear that maintaining the flag is the current issue
flowbut since I already do look over every PR and issue there, sure why not
flowI'd rather maintain the XSF's gitlab instance FWIW
KevI suggest new Council is a great time to suggest helpful process tweaks.
flowIsn't every council a great time to suggest helpful process tweaks? ;)
Ge0rGflow: the XSF hardly managed to maintain its existing infrastructure
danielthat isn’t flow’s fault…
Ge0rGflow: 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
Ge0rGdaniel: no, but adding more infra that needs to be maintained isn't going to improve the situation
danielnoise in this context was stuff council is to lazy to deal with?
Ge0rGdaniel: things that I perceived as "were addressed / voted on by council but still have the flag set"
flowI suggest that council simply removes the flag once council decides that it is addressed or no longer in the responsiblitiy of council
Ge0rGI suppose that council expects editors to read up in the council minutes what was decided and act accordingly.
flowEven then I would suggest that council simply removes the label(/flag) and ideally leaves a short comment too
Ge0rGCouncil 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.
danielYes removing the flag, leave a comment and when accepted re-delegating that back to Editor seems like a good idea
danielWhen I get onto the next council I'll happily do that. It's not that much work. #VoteDaniel
Ge0rGGo Daniel!
flowGe0rG, why after the meeting? I'd probably do it during the meeting, and ideally it is done by the current chair of the meeting
Ge0rGflow: the chair of the meeting should be busy chairing the meeting
Ge0rGflow: 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)
flowMaybe not editor permissions and maybe not require all council members to hold them (but would be preferable)
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?
pep."Got council feedback", and remove the "Needs council"
pep.Or sth
pep.And then the author of the PR would update it and readd that label
pep.Ah that as already mentioned
Ge0rGpep.: Council-Accepted and Council-Rejected plus a link to minutes / log / whatever?
Ge0rGExcept that things typically get voted on on-list
pep.Hmm.
Ge0rGIn-council-review
debaclehas left
pep.Ge0rG: then you have to trust the Needs Council label, if you want to push that or editors
pep.I don't especially want to make the whole thing even more rigid, I just want to make it clearer
Ge0rGpep.: I don't know what I want. It just seems that currently, that label is not actually well applied
pep.I'm trying to cleanup the mess that is /xeps/pulls
pep.By pinging people and having them act on that
pep.Otherwise I think I'm going to start pushing to close stuff.
pep.Or move the venue of pending things
pep.So that /pulls/ can effectively be used as an agenda
Ge0rGpep.: that sounds great!
flowThe 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
pep.Council should probably reply on the thread then
pep.Giving feedback
flowdefinetly
Ge0rGpep.: what should happen between the PR being discussed in council and all votes arriving?
pep.I'm happy with a in-council-review as you said