XMPP Council - 2014-02-05

anything on the agenda for today?

i have "talk about deprecating the compliance suite" on my list and _think_ i poked kev about adding it to the agenda

okay...sounds reasonable

You did.

It's time.

1)

I'm here.

here

here+

here

Matt sends apologies.

2) Compliance suites.

Should we be deprecating 270?

i'd say yes because it requires 3920 and 3921. which are obsoleted by 6120 and 6121

Yes

yes

yes

ralphm: Don't you try and sneak your filthy votes in :p

And yes, I agree.

the more tricky question is how we replace it. we have http://xmpp.org/extensions/xep-0302.html (comp suites 2012)

What about 305, or whatever the replacement was?

302, OK :)

302 is a better starting point at least. my feeling is that we need something along the lines of "if you're a mobile client, then you should implement..."

yes, I'd be +1 to getting 302 active when we deprecate 270

Kev: heh

fippo, mobile client column?

"if you're a web client then...", "if you're a jingle client..."

tobias: more like different tables

if we're improving 302 we should at least change its name

no kidding

I think that would be sane.

I'm wondering if a year is a good differentiator, but don't have a better idea

You'd not moving targets

want

why not remove the year?

stpeter: Because then you have to target versions, or XEP numbers.

well, if someone prints a flyer, they want a stable reference

just "XMPP Compliance Suites"

Kev: right, but we can reference the XEP number I think

We could do XMPP Compliance Suite and obsolete the old one and publish a new one with the same name every time, but that seems icky somehow.

In future, I'd say a better approach would be to make xmpp.org/extensions be able to display XEPs by use-case category

"XEP-0302 compliant"

you'd want to refer to a specific one? The document version?

It seems to me, without much consideration, that it's not a bad thing in 2014 to say you're compliant with the 2012 compliance suite.

the alternative is that we commit to updating them every year :-)

Lance, nice idea

Kev: hmm, you're probaby right

It gives people a feeling how current the document is.

(and then we update it whenever we think that's needed)

I don't feel so strongly about this that I'll fight rough consensus.

stpeter: By 'update' you mean 'publish a new year's'?

yes

This seems sanest to me.

Does it? If something doesn't change, is it stale?

ralphm: No, and I don't think that is implied.

if we decide that 2012 is out of date, we start work on a new one to supersed the old

Kev, and old ones get deprecated if new ones reach draft?

Right

ralphm: But it gives someone in 2014 who doesn't support the 2014 profile yet a bit of a get-out as to why they still support 2012 only.

hm

Perhaps drop the year and just replace the xep with a new one?

ok

I'd include the year then

Zash: That was suggested, and I prefer keeping the year, really. I don't see a strong argument against the year, other than it might make us look inactive if we skip a year - but I don't really believe that's true, either.

Mmm

We're not committing to providing a new suite every year, we're committing to saying that every time we think there's a change in the baseline required for XMPP, we'll release a new one and date it.

Kev: +1 on that statement

yeah

then we just need some text that says "this is the latest compliance suite and it will be replaced by a new one when the need arises"

yup...with a year it's also nicer to reference....as been said, without it you'd need to refer to the version all the time (the year would be some kind of higher version)

stpeter: This seems entirely reasonable to me.

Not +1, because Kev gets confused, but I agree

stpeter, +1 for some text like that

ralphm: Very kind, sir.

'+1 as well. i dont even think we need to immediately deprecate an old suite. only when it gets obsolete for some reason (as happened to the 2010)

fippo: Well, there's multiple states here we could use.

And, it's a bit of a shame that we always go through Deprecated to get to Obsolete.

Because for compliance suites we probably want to go straight to Obsolete.

Why are they Standards Track?

Kev, to change that process we'd need to change some icky ascii art, right? :)

you don't have to imo

There's no problem with implementing an old compliance suite, so they're not logically deprecated, but they are obsolete :)

no. e.g. the 2012 ones would be deprecated by 2014 whereas the 2010 ones should be obsoleted

fippo: I don't think that releasing 2014 means there's anything actively wrong with 2012, which is what deprecated means.

If Council decides it goes to Deprecated and immediately to Obsolete, that's fine

Deprecated means Do Not Do This.

kev: good point.

Obsolete means This Is Not Relevant Any More.

The old one will be marked as superseded, obsolete seems proper

We should maybe make that explicit in the red heading

speaking of which, didn't we discuss that heading a while back...?

fippo: We did.

Does everyone think we're done with compliance suites for the moment.

?

yes previous council did

If we need to, we should update XEP-1 to make this route OK. I know we've gone straight to obsolete before though, for roster versioning xep, etc

I don't see a reason to change XEP-0001

A Standards Track XEP that has been advanced to a status of Final may be superseded by a future XEP approved by the XMPP Council. In such cases, the status of the earlier XEP shall be changed to Deprecated, possibly with an expiration date assigned by the XMPP Council (see the Expiration Dates section below). After a reasonable period of time or upon the passing of the expiration date, the status of the XEP shall be changed to Obsolete.

just vote to do two steps at once

So if we feel that the reasonable period of time is measured in nanoseconds, we're golden.

awesome :)

:)

:D

this!

I think we're done on compliance suites. Including that we have voted to Obsolete 270?

+1

+1

'+1

+1

Fabtastic.

(oops, did it again)

he did it again

Haha

3) Date of next. SBTSBC?

old habits die hard

+1

wfm

wfm too

Jolly good.

4) AOB?

did the Council vote on XEP-0152?

the last call ended on January 31

Nope. I think perhaps with the new Editor team we should formalise whether they're going to keep track of LCs or Council is.

My vote is, of course, that they track them and poke Council to vote on them.

Council IMO

Kev: I'm fine with that -- the team can request agenda items

I note that at the summit I asked a room full of XSF members to raise their hand if they were not volunteering for the Editor team, and no-one did. So every XSF member present who isn't already on Board or Council has volunteered to join that team :)

hehe

I'm not quite sure why people then started calling me Evil Kev.

*phew* ;)

Kev: we could all learn from your management style :-)

we had sufficient applications, I think

ralphm: Yes, I think so.

ralphm: yes, I will schedule an organizational meeting next week

I /think/ that we decided that Council would then select from that pool, but I should check.

that's my recollection

we need to get the UPnP liaison team going, too

(I anticipate Council's selection being "You want to do it, good [man|woman|other]".

Yes, I have a TODO to chat to you.

ok

I think we've not got AOB, but we do have 152 for the agenda next week.

sounds good

evil kev: does tobias get to "vote" on the resolution we made at the non-official impromptu meeting on wednesday evening?

fippo: I think simple majority works there.

Anyway.

Thanks all, I think we're done.

Thanks!

thanks

(The informal Council vote in question was "Should Council decide to be evil?" it passed with 4/5 of Council present :))

4/5 votes yes, let's be evil or no?

stpeter, just blame xnyhps :)

:-)

well, Adium would connect yesterday, but not today :-)

maybe an easteregg

I suppose I ought to join the xsf@ chatroom, eh?

stpeter: Security feature?

stpeter: yes please

Board meeting in a few minutes