XSF Discussion - 2019-12-03

yes, this allows me to properly setup the popup window and negociate the jingle call after that

is our wiki down? or it is just me...

it's back...

there has been a very high delay on xmpp.org and jabber.org... for me

yeah, it’s been flapping here, too

Oh I thought my s2s was broken just now

I just had IPv6 issues, it seems

ok... hey do we have some monitoring on our infra?

We don't

I guess we should... should we put such an item somewhere close to the top of the task list of the iTeam? I mean no harrassment

It's somewhere below "First draw up a list of what servers and services we are running"

ok, thx :) May The Force Be With You

Speaking of iteam, I'm updating Github permissions as we discussed in one of the recent board meetings

Anyone who doesn't have access to something they think they ought to have access to, feel free to poke me and I'll investigate

Who should have access to what?

The main change is that there is a (hidden, iirc) "Web" team

which has a bunch of people in it

All the people who are actually doing stuff are already in teams that already have access to the relevant repos

So the goal is to simplify Github permissions so they align with XSF team membership

which will make it easier to see and manage who has access to what

to clarify what I wrote above - the "Web" team exists, but is being removed in favour of more well-defined teams

:)

Link Mauve is popping up a lot

Are you actually in any formal teams?

I don't think he is

There is a team called "xep build" with literally just Link Mauve in it

:D

He just helps a lot

But I don't think he's got any commit rights

(or should have by the definition above)

"xep build" has read access to xep-docker-base (but read access is already default for all org members), and write access to xsf/xeps

oh

Maybe he should "just" become an editor

Well, as per the discussion, this team is going - and if someone tells me Link Mauve has become an editor, then he can be added to that team

But like all MUCs, he seems to be in them all anyway somehow

MattJ, sure, let that team go :)

Done already

k

Link Mauve, ^ you know what you have to do now

(apply to all the teams \o/)

We have two Github org members who don't appear to be actual XSF members (now) - Matt Miller and Sam Whited

Both are in the Editors team on Github

The Editors team can only be members, IIRC (don't take my word for it), so I think they've naturally fallen off.

Agreed

Hmm, seems there's one more that shouldn't be there according to a count...

Guus is not listed here: https://xmpp.org/about/xsf/editor-team.html

I'm not an editor

Yet is on the Editors team on Github

Ok

Ok, done

Now we have two Github members without teams: Alex and Link Mauve

Would be good to figure out what Alex needs access to

We can have a secretary team I guess if necessary. What does the secretary have to edit? xsf/xmpp.org? (I wish we could have finer grained permissions in repos)

You can have individual permissions (in fact that's what Alex has for xmpp.org)

I usually only edit content

MattJ, yeah but if/when Alex leaves the position, then we're going to have to go through that again, whereas we could just swap people in a team ("role") otherwise

MattJ: Am I in iteam?

Yep, I'll create a team

have plans to move memberbot to our Github org when thzere are no concerns. Lance archived it on Github https://github.com/legastero/memberbot

Zash, in the team yes, in Github I can check

> have plans to move memberbot to our Github org when thzere are no concerns. Seems sensible

Agreed

Ok, pretty much done

There is one more team I would like to solve, there is one called "Core" that just seems to map to a handful of arbitrary trusted people

It seems that should be replaced by org admins and/or iteam

Sounds good, MattJ

admins?

I just got an email notification after being kicked out of a team

Core can probably go, I guess. Most people in there are org admins.

Owners, rather.

With Alex being an Officer, maybe you can create a team for officers, and put Peter in it, too.

Kev, should they though

so people that are worried about loosing access have a chance to complain

Actually, all people, by the look of it?

pep.: And yes, I'd arbitrarily claim that all the people who're org owners are sensible to be org owners.

Kev, yep, looks like all Core members are org owners... I'll remove it

Kev, I don't even know who is org owner

Ah I can see it, cool

I disagree

hmm ok intosi and stpeter are also in iteam

With the exception of Ralph, it's a subset of iteam selected by the (then-)iteam lead.

Guus, didn’t you leave iteam?

I did

Yeah, I'd say all Board + iteam are candidates

I was wondering

I thought Guus had removed his sudo, but was still on iteam.

MattJ, tbh I'd vote for board not to be owners, iteam is good enough

I'd be happy with it being an iteam subset, selected by the iteam lead. Same as who gets sudo on boxen.

let's not have half-members of teams - that's just complexity that we can do without 🙂

(I don't mean it's the same list of people, I mean it's the same 'iteam lead gets to make sensible iteam decisions')

Matt might reasonably disagree with me on who a sensible subset of iteam are, naturally :)

I think the team, whatever its name (Core, Owners), is good as it is.

It's gone :)

or "the set of people that are owners"

It was unnecessary and confused thing. The only thing up for debate right now is who should in the owner list of the Github org

*confused things

As I said, it seems fine to me like this.

Same here, especially since I've run out of any more time to spend on this today

yay

Thanks for looking into it.

And, regardless, I think Matt gets to make the call.

yes

But now we only have Github teams that are actual XSF teams (or roles), and the only members of those teams are people who are officially members of those XSF teams

and so does Board, by the way, as we discussed a few meetings ago

👍

Board shouldn't be interfering in iteam.

right

if anyone wants to engage: https://fosstodon.org/web/statuses/103243542343931019

Newsletter sent PR merged for the blog post: https://github.com/xsf/xmpp.org/pull/660

thx for the rights to merge

now should I do anything else to deploy?

Doesn't The Cloud do that automagically?

nyco, CI should take care of it

then: > now should I do anything else to deploy? 1. Wait

thx

aaaand the wait has been... long! https://xmpp.org/2019/12/newsletter-03-december/

ARGH! there's a article in the newsletter that advertises to install dino from snap. That's a terrible idea, the snap is 3 years old and isn't maintained 😢

hm, my agenda announcement is stuck in the council@ queue. can someone please check which of my addresess is listed as being allowed to send to there?

last council mail I received went to teh address I used to send the agenda

jonas’: standards@ has passed through, so it's probably not too bad.

jonas’: I'm most probably going to miss tomorrow

jonas’, I seem to have received it

Zash, I sent to both standards@ and council@

so you probably got it via standards@

Oh, yeah

Ge0rG, noted, thanks

Ge0rG, although it’s a pity because there seems to be plenty time for your stack of AOB

jonas’: I'm unprepared and I forgot most.

I bet we could find them in logs ;)

jonas’: also apparently Council is not there to do guidance on how the standard should evolve, but merely for voting on submissions

"apparently"?

jonas’: what about calling up https://mail.jabber.org/pipermail/standards/2019-August/036332.html for discussion tomorrow, then?

Doesn't mean you can't do stuff

I can't do stuff

Council status doesn't stop you

Neither does lack of council

I'm blocked on my own segregation of duties issue.

I am doing some cleanup of old code in Openfire and wanted to get a feel of who else in the XSF community is still supporting XEP-0136: Message Archiving and older versions of XEP-0313: Message Archive Management. Is there anyone supporting an xmpp server or client that still handles the urn:xmpp:archive, urn:xmpp:mam:1 and urn:xmpp:mam:0 namespace?

Prosody only includes MAM :2 out of the box.

The there existed a community module for XEP-0136 but it was removed long ago.

ejabberd supports them all out of the box. But isn't the real question whether there are still many clients in the wild not doing :2?

Holger: could you measure that on your deployment?

Well, not without touching the code …

How fast does the XMPP world move?

I would think there should be quite some incentive for client devs to go for :2 as dedup is such a PITA without stanza IDs …

But no idea about the implementation status.

Thanks for the quick response. I was going to remove support for xep-136 and keep only mam:2 🙂

Er yes ejabberd doesn't do 0136 anymore either. Just the older MAM versions.

I think Vacuum IM does 0136 …

https://stats.jabberfr.org/d/000000002/jabberfr?orgId=1&fullscreen&panelId=39 lists client features fyi

Do clients advertise MAM tho?

mam:1 and mam:2 are listed there at least

It's been 3 years.

I would imagine there be more support requests than there are if mam:1 was something people needed. There were some long ago tho.

if you implement mam:2

you can just announce mam:1 aswell

its a subset

the only difference is guaranteed stanza-id on mam:2

dont implement 0

because its different protocol wise

I can run some statistics in the CAPS that I store in Movim

But on my side I only support :1 and :2 I think