peterset the topic toXMPP Council Room | https://xmpp.org/about/xmpp-standards-foundation#council | Room logs: http://logs.xmpp.org/council/ | https://trello.com/b/ww7zWMlI/xmpp-council-agenda
danielhas left
danielhas joined
danielhas left
danielhas joined
Davehas left
Davehas left
Davehas left
Davehas left
peterhas left
Davehas left
DaveAfternoon. I'm less rubbish than last week (in as much as I'm here), but more rubbish than I should be because I havem't had a chance to do the agenda.
DaveThis is definitely on it though: https://xmpp.org/extensions/inbox/muc-avatars.html
DaveSo this would be the agenda, if I read correctly: https://docs.google.com/spreadsheets/d/1AZ-Sna6OiRG--b-mJMKv3XXfrn3Nehm0kAtlyJvImL0/edit#gid=0&range=B93
DaveNo, some (many) of these have been voted on.
DaveRight, corrected, though I'll fill the votes in later for the ones that have been done.
SamWhitedcrams before the meeting
DaveRighty, 'tis time.
Dave1) Roll Call
DaveWho be here?
KevHere. Entirely unprepared, but here.
DaveI'm pretty unprepared as well.
SamWhitedI am here, and have read at least one of the protoxeps
SamWhitedBut also pretty unprepared
DaveSamWhited, There's only one protoXEP, plus one PR.
SamWhitedOh, I thought a second one came in. I have read the protoxep!
KevI'll try to get this one on-list, but realistically I'm flat out until holiday and it might expire.
ZashI heard Georg is on vacation
DaveI'm +1 on this, though i would like to understand how it differs from the de-facto that it suggests exists.
SamWhitedI'd be curious to hear what others (especially client authors) think about this one. I tend to think it's unnecessary, because you can just do it all already as far as I can see and having a second XEP that says more or less the same as vcard-temp feels awkward to me.
danielMinus presence plus in Disco info
Link MauveDave, I tried to explain that in both the introduction and section 5.2.
KevI'm +1, have just scanned it.
danielBut I'm not entirely sure about the motivation
Link MauveSamWhited, I hesitated about making it just informational, still not too sure.
DaveLink Mauve, Ah, I thought that was just about presence.
DaveSamWhited, It's mostly usage and semantics rather than protocol, but it seems useful to document.
SamWhitedThat might make a bit more sense, having a standards track XEP that rehashes a historical one and adds discovery just feels odd
Link MauveDave, presence vs. disco#info is the only part where my proposal differs from the status quo.
DaveLink Mauve, Gotcha.
SamWhited"That" == "Informational"
danielBut since servers will do that anyway now I don't think that this xep will retroactively fix that
danielI mean sorry that clients broke and all
SamWhitedDocumenting things sounds find, but it feels poor to have multiple XEPs in various states documenting the same thing. Couldn't we equally just add a note to vcard-temp saying "remember, MUCs are JIDs too"
Link MauveAt least Prosody will probably skip on the presence way.
danielBut the demage is done
danielBut we don't have to discuss this on council
SamWhitedOr a nod to vcard temp in 0045 even
DaveSamWhited, Are you voting on this or thinking? (Georg is presumed to be on list anyway)
danielI'm +1 and then we can discuss on list once the xep is out
SamWhitedI'm thinking out loud, just curious to get others opinions. I guess I'm on list. I'm hesitant to publish this, but it seems fine protocol-wise.
DaveCool.
genofirehas left
Daveb) XEP-0060: Add an example on returning fewer items than requested https://github.com/xsf/xeps/pull/695
danielAlso really if your client breaks if you get a presence from a bare jid. Wtf. Just fix your client
danielThe neat thing about doing the presence hash thing is that it worked instantly w/o any changes
Davedaniel, Feel free to argue this position on list. :-)
DaveAnyone any votes for this PR?
DaveI personally think it's straightforward, so +1.
SamWhited+1 on the PR, though I'll leave an editorial note for the author, but it won't change the substance of it
KevI'm not sure why this is a thing. What's the backstory here?
DaveLink Mauve, ?
DaveKev, FWIW, the XEP doesn't say what happens if a clientrequests N most recent when there are only M (M < N) items present. This is the obvious thing to do.
KevIt being the obvious thing made me wonder why it needed to be a thing.
Link MauveHmm, it was during the XMPP Sprint with MattJ, we IIRC encountered a case where Prosody was sending back an error instead of zero items.
Link MauveThis makes sure servers behave correctly in this case.
KevFair enough. No objections here.
DaveKev, Is that a 0 or a +1?
daniel+1
SamWhitedAdded some minor nits on wording; only the first one really needs to be fixed. The other is just me being picky and I don't think it actually matters, feel free to disregard.
SamWhited(I'm +1 either way with my council hat on, nits are with my editor hat on)
Kev0 because I don't have time to do the full review involved in +1ing it. The patch looks fine, but I don't think it's sufficiently diligent to approve just based on the diff - we know how that has worked in the past with complex XEPs like 50.
DaveOK
Dave3) AOB
labdsfhas left
KevNowt.
Dave4) Next Meeting
DaveI saw you were saying you'll be away for a bit, Kev?
labdsfhas joined
KevI'm out of action until October.
DaveAnyone else going to be MIA?
Kev(That'll be fully out of action, not on-list, unfortunately)
DaveI have no idea how you'll survive.
DaveI'll assume the rest of us will meet same time, same channel.
SamWhitedWFM
DaveSo absent anything else, thanks all, see you next week.
Dave5) Ite, Meeting Est.
Syndacehas left
Syndacehas joined
Link MauveBtw, there are still quite a few outstanding PRs at https://github.com/xsf/xeps/pulls which are tagged as Needs Council, could you add them all to next week’s agenda?
DaveLink Mauve, I believe that those have had votes and expired. I'll see about tidying these up and ensuring they're documented etc.
Link MauveTa.
guus.der.kinderenDave: #579 was voted on?
guus.der.kinderenThe h thingy on SM
guus.der.kinderenIt was in February, but was modified since.
peterhas joined
Kevhas left
Davehas left
Lancehas left
Lancehas joined
Lancehas left
Kevhas left
martinhas left
genofirehas left
martinhas joined
Davehas left
Link Mauvehas left
labdsfhas left
labdsfhas joined
Davehas left
genofirehas left
labdsfhas left
martinhas left
labdsfhas joined
jonaswhas left
labdsfhas left
Kevhas left
Davehas left
Davehas left
vanitasvitaehas left
lnjhas left
lnjhas joined
martinhas left
martinhas left
martinhas left
Davehas left
Davehas left
genofirehas left
jonaswhas left
labdsfhas joined
labdsfhas left
labdsfhas joined
SamWhitedhas left
danielhas left
labdsfhas left
labdsfhas joined
danielhas left
flowguus.der.kinderen, #579 appears to be conflicting with master (at least gh tells me so)
labdsfhas left
labdsfhas joined
labdsfhas left
labdsfhas joined
flowguus.der.kinderen, I would suggest squashing into a single commit and rebaseing on the current master