XMPP Council - 2019-07-10

I’m accompanying a friend to a train station this afternoon, I may not have Internet at the time of the meeting, but I’ll attempt to.

I may be late by five minutes or so, I'm stuck in public transport.

I'm almost there, still hanging in a conference call

I found a free wifi, I’ll be here.

here I am

Sitting on the floor in a train station, with many other people waiting for their train.

Afternoon all.

afternoon, chair

looks like Link Mauve is the one who needs a chair.

don’t we all?

The floor is comfortable, I’ll let you chair.

now stop the chairity.

dwd: are you waiting for more silly chair jokes, or just got distracted?

It looks like we have a quorum, so maybe we can start nevertheless. I'll try to fake Dave until he reappears.

1) Roll Call

dwd, jonas’, Kev, Link Mauve?

Yup, I’m here.

I’m here, too

(your connection is ok, Ge0rG ) ✏

Guus: :D

two out of five. I vaguely remember Kev sending apologies, but probably only for last week.

2) Agenda Bashing

Ge0rG, also this week

There was no further input on the ML, and we have two items.

two items for vote, that is.

Anything else?

> I'm likely to be absent again this week, sorry. Kev, Yesterday ✏

not from me

Let's go on then.

3a) XEP-0128: Remove 'unlikely' statement. https://github.com/xsf/xeps/pull/797

+1

This looks straight-forward and I'm pretty sure it's not a breaking change.

+1

+1

Awesome. If Dave happens to re-appear, he can cast his vote as well.

3b) XEP-0368: clarify what happens when a `.` target is published. https://github.com/xsf/xeps/pull/796

+1

Definitely +1 on this.

+1, as this is just a clarification of what's in RFC 2782

4) Outstanding Votes

I still don’t know what to do about the jingle things

That's an awesome AOB actually

peter, great!

although that has resolved itself because it expired / vetoed with several -1 because nobody had an idea what to do about it

Dave Cridland: who are you and what have you done to dwd?

I read the mails by fippo but those weren’t a clear +1 / -1 for me

We also have two votes that expire today, with missing input from Kev and Link on https://xmpp.org/extensions/inbox/xep-sce.html

Sorry, seems my DSL at home went down at exactly the wrong moment.

And my j.org account has months of spam to download from offline storage...

Dave Cridland: that adds to the voting spam from this MUC

5) Next Meeting

Ge0rG, still on list for me, I haven’t reviewed it yet.

+1W?

+1W is good.

+1w wfm

Same.

Great.

sorry, didn’t realize you were waiting for input :)

6) AOB

6a) Jingle and other "special skills" [Jonas]

jonas’: do you want to make your point first?

can do

so, my point is that Jingle and possibly other subprotocols of XMPP are rather complex beasts, and I find it very hard to judge whether a change is sensible without having implemented it myself

I do sympathize - I've never implemented Jingle either.

Jingle is my main issue right now, because I have sunk several hours into reviewing MIX in depth and took MIX into consideration when I wrote my MUC implementation, so I have a rough idea how things work there; same for PubSub.

I second that, PubSub is another candidate for this category

so I don’t really feel confident when voting on Jingle things

which is probably not a good thing

now others have mentioned that the Jingle veterans like fippo and peter would be qualified to give reviews, which makes sense to me

and which would, in my opinion, be a sane way forward

jonas’, it’s the opposite for me, I feel Jingle pretty well, but MIX is still foreign to me.

(although we might be the people posting PRs too)

it would of course be even better if council had actually the technical understanding itself, but that’s probably not realistic for all the 400+ things we have

The alternatives would be: - create a Jingle SIG - force all Council members to implement Jingle

deferring to the authors would effectively mean that we treat Jingle like any Experimental XEP

modulo that someone like Link Mauve may be a gatekeeper, too

I think that formally, we should aim for something like two (or three) independent reviews from people who were not involved in the PR

However, my view is that we're voted onto Council and we have to have to final say. How we reach that decision is, basically, up to us - you're welcome to defer to expertise like Fippo if you like, or something else.

But I'm all in favour of getting independent reviews.

From the floor: is this to be a consideration when accepting future, new, possibly complex XEPs?

so my course of action would be to ask on the mailing list for specific +1/-1 feedback on the PRs from the jingle veterans

Dave Cridland: I'd like to prevent a situation where all five Council members privately ask fippo for feedback and base their decisions on that

Guus, not necessarily from my side. sometimes complexity is necessary. I’m not saying that Jingle is too complex for what it does

A SIG for each complex area would be a very formal way to do things.

and too much organizational overhead IMO

I'm fine with just asking for +1/-1 from veterans on the list.

I just wonder how we define who qualifies for a veteran.

author and/or implementor during CFE

^ this

Or maybe this is something we as Council members can do implicitly. Ask for public review, wait, -1 if there is not enough feedback

Please do feel free to flag me on PR reviews in GitHub.

Same for others, I'm sure.

peter, is pinging your github name enough?

Ge0rG, How about we discuss who we'll ask for reviews when things come up for voting that we'reuncomfprtable with?

Dave Cridland: that's perfectly fine with me

So when such a vote comes up, we defer it and define a list of people to consult.

That's probably the right choice. And I've usually found that one decent reviewer is often enough to spark a discussion which illuminates the issues.

I think we can move forward with that.

And as Dave says, it's up to the Council members to come to their own conclusions.

peter: indeed.

Do we still need to do so for https://github.com/xsf/xeps/pull/793 ? Probably yes.

Ge0rG, yes

I balloted on lots of RFCs while I was on the IETF, but I didn't make as many comments on routing specs (that's not my area of expertise) as on apps/real-time specs.

s/IETF/IESG/

can we start this process right now for #793?

Yes.

then let’s do that

peter: do you feel confident to review #793 and to estimate its implications?

(also able to review it in two weeks time?)

Yes, I can commit to that.

peter: thanks very much.

I also don't see a clear indication from fippo's email. We probably should ask for a clarification.

Any other suggested reviewers?

Link Mauve, obviously. You didn't vote the last time. Can you review the PR and make a public statement on the ML thread?

We are also a bit over time already.

Also it seems like we've lost quorum.

I’m here

but yes

Dave Cridland: do you have suggestions on whom to ask for reviews of #793?

Ge0rG, ok, I will do that.

Link Mauve: great, thanks

7) Close

Thanks everybody.

Ge0rG, Thanks for stepping up there.

thanks Ge0rG

Thanks. :)

Please note that I am interrupt-driven, so feel free to poke me if I haven't replied in time!

(well, interrupt-driven and also overloaded in my $dayjob)

Lance is another possible "Jingle veteran" who could possibly review PRs. :-)

Lance: could you also have a look at https://github.com/xsf/xeps/pull/793 (is it useful? does it break things? is it an incompatible change?) and provide a feedback on the standards@ ML? That would be highly appreciated

Yeah, I can do that today

My review of that PR is that, although I agree entirely with the sentiment, the change would be breaking, and by itself is not worth the namespace fracturing.

ge0rg: i would only do a "first thre get served" to ensure my opinion has a majority :-)