XMPP Council - 2019-10-25

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

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

2 month? What?

Council can just vote on the officially next meeting?!

Just an estimate of the mean voting period :P

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

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

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

They were added rght when council rejected it

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

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.

the server will not send that?

except as the current value in a user defined configuration

or i'm missunderstanding what you mean by server set

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

it could be be the default of that configuration

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

do you know what the max_items config option does?

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

i'm talking about the node config

it is not being used for pagination in there

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

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

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)

*for a user

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

ok.

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

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

because it might not be 'unlimited'

yes.

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

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

the server will not set it to 1024 or something

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

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

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

daniel: understood that now

it was mostly my own confusion

(due to my own lack of experience with pubsub)

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

i'm not really sure how to fix that

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

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

daniel: those were different times, I suppose

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

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

daniel: seems that nobody is

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

but usually you don’t have to do that

because draft xeps shouldn’t need that amount of changes

yes.

Except that both PubSub and MUC are full of holes.

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?

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

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

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

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

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

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

flow: the XSF hardly managed to maintain its existing infrastructure

that isn’t flow’s fault…

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

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

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

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

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

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

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

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.

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

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

Go Daniel!

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

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

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)

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

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

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

Or sth

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

Ah that as already mentioned

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

Except that things typically get voted on on-list

Hmm.

In-council-review

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

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

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

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

By pinging people and having them act on that

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

Or move the venue of pending things

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

pep.: that sounds great!

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

Council should probably reply on the thread then

Giving feedback

definetly

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

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

Once it's picked up on the agenda