XMPP Council - 2017-06-21

https://mail.jabber.org/pipermail/standards/2017-June/032993.html

better late that never or something like that

Nice; thanks!

I'm looking forward to reading that; I was getting pretty lost in that discussion after a while.

Oh, thanks!

it's about time

1) Roll call

here

Here

Here

Link Mauve, ping

Here.

2) Minute taker

i can do it

great..thanks

3) OMEMO

I've sent my OMEMO discussion summary out finally, sorry for the delay.

It seems the XSF editor hasn't sent a mail about incoming OMEMO protocol change https://github.com/xsf/xeps/pull/470 yet. Do we want to vote on it anyway?

It doesn't seem like we've come to any conclusion yet about which OMEMO protocol changes should be merged / mailed about.

Maybe we should wait now that the summary is out to give people time to respond / reevaluate based on the summary?

yes i think we should wait for the responses to your summary

SamWhited, that PR is about just having a version in the OMEMO XEP that represents the current implementation state

otherwise i don't see the point of that summary

from there one of the other PRs can b e looked at

daniel, alright..then let's wait a week.

daniel, true..makes sense :)

That may be fair; it did seem like there was consensus around documenting the current thing at least

The other PRs are more or less orthogonal to that

i took Florians email as a disagreement with that??

but to be honest i didn't read that thread after flos initial email

OhOh, I thought Florian was all for that but just didn't want it to change afterwards? Maybe I need to reread

SamWhited, that's what I thought too, that he'd generally favour going along with libsignal as that's what everybody implements

> he council will likely soon [1] decide if the currently used OMEMO

protocol will be published as the next version of XEP-0384. While that

is great, the plan is to shift following versions of that XEP away from

the Double Ratchet Algorithm using XEdDSA.

> SamWhited, that PR is about just having a version in the OMEMO XEP that represents the current implementation state

*facepalm* sorry, I always forget to go into multiline mode

ok maybe i'm wrong. in any case let's wait a week with that vote

Yes, but whether doing that is appropriate depends on the outcome of the 'what should be happening'

e.g. if the outcome was "document OMEMO-SIACS in a new Historical XEP", publishing that wouldn't be appropriate.

Sounds like it's worth waiting / discussing that more or separately then; I was under the impression that documenting OMEMO-SIACS did more or less have consent though and that afterwards it could remain the same, or change to either Remko or Andy's proposals

I think it only has consensus if the plan is then to continue development in the normal process.

If it's to allow current implementations to hold the standards process hostage, then obviously the compromise falls apart.

right

but anyway, let's revisit that next week then

4) Deprecating XEP-0146: Remote Controlling Clients

didn't we vote on that last time?

Not that I can see from the minutes

maybe...don't have minutes for that in my mailbox...unless they will appear soon I suggest we revote

oh it was two weeks ago

and we don't have minutes of that

I think it was two weeks ago, and I seem to have forgotten to send the minutes. :x

I will handle that asap.

But we did decide to vote to obsolete.

and yes...i still haven't got muc logs working again...now that the omemo summary is out i'll do that next

Link Mauve, do you have the contents of that meeting or want us to revote?

Also, was it to deprecate or obsolete? I vaguely remember talking about obsoleting it, but don't remember which ended up being picked

Yes, I do have it.

great

SamWhited, obsolete right away.

*nods*

that's what I remember..ta

obsoleting. but lets wait for the minutes if Link Mauve still has the logs

I’ll send an email shortly after the meeting.

would be nice to reflect the voting info in https://trello.com/c/35xYY09j/185-vote-on-obsoleting-xep-0146-remote-controlling-clients if possible

i think for the other points in trello we were wainting on editor mails

5) Date of next

Ok, we didn’t all vote, I’ll reflect that there.

I might not make it next week, but feel free to meet anyway

otherwise same time, day next week

WFM

wfm

WFM.

7) AOB

I would like to advance 363 http upload

That seems like a good plan / worth discussing to me.

Sounds sensible.

i think we need to vote before it moves to Proposed and before it moves to Draft

at least according to https://xmpp.org/extensions/xep-0001.html#proposal

I’m +1 on that proposal.

Vote to move to LC?

right

my plan was we vote to move it to proposed which will trigger a discussion on list. and after two weeks we can vote again to move it to draft

ok

daniel, yes, that’s the process.

8) Vote to issue LC on XEP-0363: HTTP File Upload

+1

+1

+1

+1

Dave Cridland, ping

That one might trigger some discussion, but I think it's a good one to be trying to advance :)

(I also have some AOB that will relate to this and might affect the timeline, but we can and should definitely vote first and figure that out later)

well..Dave can vote on list I suppose

9) AOB #2

SamWhited, what's your AOB?

(I also have an AOB about the current staleness of the editor process, which might be the same as yours but from the user point of view.)

Probably the same :)

I would like to put out a call again for more active editor volunteers; we got a bit of interest last time, but I am still effectively the only active editor (and I'm not active right now, so that's a problem).

However

Oh. Sorry, I didn't expect voting during AOB. +1, then.

I don't think putting out a call will actually help, so I'm not sure what to do. The process is and always has been too cumbersome, which is why I think we haven't had more than one editor at a time recently, why other active members don't do editor work often, etc.

FWIW, I would have been doing more Editor stuff if not for Iteam stuff. But yes, expanding the team sounds very desirable.

I'm not sure what we could do to fix that though.

If we can expand the team and work will get done, great, but I'm not sure that actually expanding the team will help.

The related part is that the LC proposal email probably isn't going to go out, so can we really vote in two weeks if no knows we're maybe moving to LC?

Asking for someone to volunteer to do a bit of script work (as requested by the Editors, not based on what they fancy coding) might go a long way.

We have tried that in the past; the people who volunteered decided that everything needed an immediate ground-up rewrite despite what I think was effectively both of us cautioning against that

I know you don't like the time it takes for Docker to build, but that bit is now automated, at least. If we could automate the emailing too (or script it sensibly so you just say "Send these mails (based on recent git changes) please") that'd help.

You'll note how I said about doing what the Editors needed, not what someone fancied writing :)

SamWhited, is this a reference to winfried’s XSF-Tools?

The Docker stuff is both better and worse; I agree that having it automated is better (except it's not really, I still have to deploy it), and I accept that it will take longer because it's building all XEPs, but when I've tried it it has taken an hour to even *start* the build

Link Mauve: No, since then, but that too IIRC

I would be happy to write up what I see are the main problems (I think I've done this in the editors room a few times, but not in any consumable way), but I just don't know where to go from here as far as fixing it. I'm pretty tired of dealing with the editor process myself, but don't want to just quit and leave people in the lurch. Anyways, suggestions welcome.

I'm reluctant to have it autodeploy, but it's not out of the question.

Autodeploy based on a git push?

SamWhited: How about you write up a mail to me with what you think are the issues, and we can to-and-fro, and then come up with a Trello board that lists the steps to get where we want.

At least then we'll know what needs doing, even if not who'll do it.

Kev: That sounds like a great approach, thanks

I suspect there are enough people in the XSF who'd be willing to do a very small bit of dev work for an hour just to tick one thing off the list for us.

As long as we get the list right.

yup

That might avoid the "I volunteer, but only if it's for a full rewrite" issue too

r

Which reminds me that during the move to docker, some XEPs that had never been updated in hg got updated without an email, I’m thinking especially about 0030 2.5rc2, but that might be another AOB.

Sounds good; I'll start an email to Kev after this then and we'll come back with recommendations later.

Link Mauve: If you know of things that are wrong, can you mail both council and editors, please?

Ack.

In theory, what was in Git should have been what was published, but likely this wasn't always the case.

SamWhited, does this conclude your AOB point?

We *used* to not publish master, but just publish individually when ready. It changed a few years ago.

Tobias: I think so :)

Tobias: It does; although we probably still have the issue of sending out a LC notification.

Link Mauve, what about your AOB point?

Tobias, it was the visible part of the previous discussion, “pull requests don’t get merged currently”.

alright

any further AOBs from anyone?

doesn't look like it

Thanks all.

thanks everybody

Thanks. :)

will try to get prosody muc logs working for this and otehr muc.xmpp.org rooms real soon now

maybe friday or so :)

Trello updated with the vote on 0146.

i probably said i'll vote on the list ^^

You did. :)

> If it's to allow current implementations to hold the standards process hostage, then obviously the compromise falls apart. Kev: I wanted to wait for the council meeting to be over but I have no idea what you mean by that. how can implementations or implementors hold the standards process hostage?

I was also going to ask about that but forgot; I had no idea what that meant.

It was badly phrased, perhaps, but there has been an argument presented of "There are deployments, we don't want to change deployments, so the XEP shouldn't be improved", or so it felt to me. I feel that, while we shouldn't be making gratuitous changes where avoidable, we should not be tied to the current implementations where there are improvements to be made - that's the point of Experimental.

If people don't want any changes made to the spec for fear of making existing implementations need updates, we're not talking about standards track specs.

I don't think we're not making changes to the spec; even Andy's changes were pretty major changes. If we're talking about "normal" experimental XEP process I think we'd just merge the authors changes and move on.

SamWhited: well, yes and no. In the normal experimental XEP process, the Author would be required to be trying to participate in the ongoing process as well, rather than just pushing private updates.

So, from my point of view...

I don't think there was a private update; he pushed to GitHub, made his arguments why he thought it was a better PR than the alternative one

and that would generally be the end of that

I have a slight concern that some people (and I don't mean Daniel, and I don't *think* I mean Andy), might start arguing once the XEP is updated to reflect what they do in their implementation, that it shouldn't be updated again. That's why I think the two parts are important to clarify at once.

Fair enough; there may be a few that would take that view.

It could be my perception. My perception has been that discussion has been happening onlist without Andy's involvement. Possibly because that's because his discussion is happening on github, but that's not an XSF venue for discussion, and possibly because I'm just straight out wrong.

I think Andy made his points, and now the same arguments are being rehashed and he doesn't feel the need to make them again (though I wouldn't want to put words in his mouth, I think I'm paraphrasing him correctly)

I could be wrong.

Andy-bashing is certainly not the core aim here.

> might start arguing once the XEP is updated to reflect what they do in their implementation, that it shouldn't be updated again. neither andy nor myself would have a say in that anyway? the XEPs get changed based on the 'consensus' not based on what andy or myself think (ignoring that i'm on council and could theoretically veto further changes which would be an absue of my council power and will lead to me not getting re-elected)

Well, you can make a lot of noise about it on the list.

I don't know if that would be an abuse if you actually think it shouldn't be updated anymore; I also do think it's not really consensus based in experimental is it? It's mostly what the author wants until it gets voted on for moving forward (although they should certainly listen to consensus if it forms)

SamWhited: No, it's the Author's job to reflect consensus in their edits.

While this usually means just the author making the edits they want, because they agree with the consensus, it doesn't necessarily.

They should definitely listen to the community, but if there's a PR from one or two people and they say "I don't think this is a good idea", we generally defer to the authors expertise there, no?

That's what usually happens because we're usually all amicable and sensible, yes.

But in theory, an Author could reply to PRs saying "No" when the PR reflects community consensus, in which case the appropriate thing would be for Council to find a new Author.

The Author isn't really meant to be the gatekeeper on edits, they're meant to be the voice of the community.

That seems fair; I suppose what I'm arguing is that that is not the case here. I see no consensus, and therefore I think we should probably juts let the author continue to develop the XEP and if consensus forms we could revisit then.

SamWhited: I think that where there's no consensus, the appropriate thing would be to build it, rather than to plough along without it.

The longer things go without addressing issues, the worse they get, generally.

Hmm, possibly fair, I need to digest that.

fwiw i think in that particular case we lost andy as an author anyway (I don't speak for him). so if we want to develop omemo further we might need a new author anyway

That was also the impression I got, though I hoped to convince him to change his mind

when he signed up for gsoc i don't think we was planning on making it a full time job collecting feedback and changing the xep into something that vastly diverges from what it is now

especially since he is not really involved in the xmpp community (besides being a user)

I think GSoC students authoring XEPs is a double-edged sword, FWIW.

I think it's great that if they're interested in getting stuff standardised that they get to be involved, but if they do the normal GSoC student run-off-at-the-end-of-summer, we end up with an inactive Author.

Additionally, XEPping doesn't count as an activity under GSoC, which is for writing code, so we need to be careful when accepting students planning to XEP as part of the summer.

Yah, as long as they implement it too (like Andy did).

Kev, well a) andy stuck around for a long time even after gsoc was over b) that can happen with all authors. because one day they work for a company that does IM and the next day they don't

It's a complicated issue, at least.

given that the process takes years

daniel: Yes, all true.

> one day they work for a company that does IM and the next day they don't

it's me!

This wasn't an Andy rant, this was a general observation of the dangers (and advantages!) of GSoC students writing XEPs.

The incidence of GSoC students working on something for 3 months and then vanishing are much higher than of people working with XMPP and submitting a XEP and then immediately changing job, I think, although the latter is certainly possible.