I have a hard cut in +30m due to a company-wide corona party, so let's not stretch too much today
dwd
Mexican beer?
Ge0rG
I have no idea.
jonas’
1) Roll Call
daniel
here
Ge0rG
Zash
here
undefinedhas left
jonas’
I’ve spotted a dwd already, so full house, excellent
jonas’
2) Agenda Bashing
jonas’
anything to modify?
jonas’
assuming no
dwd
Not from me.
jonas’
3) Editor’s Update
- Calls in progress
- LC for XEP-0338 (ends on 2020-06-30)
jonas’
4) Items for voting
jonas’
4a) PR#959: XEP-0156: reorganize stating XRD/JRD requirements
URL: https://github.com/xsf/xeps/pull/959
Abstract: The reference to RFC 6120 was incorrect, what this really meant is RFC 6415. But instead of simply s/RFC 6120/RFC 6415/ here, I decided to reorganize stating the requirements of XRD and JRD a little.
jonas’
This PR was amended to address council feedback from last session and is on the table again.
jonas’
+1 on the PR now
Zash
+1
jonas’
I think it improves the wording and could even count as editorial at this point.
dwd
+1, though if we want to change the last bit to read "additionally", that'd be possibly clearer.
jonas’
oh, though, it makes JRD SHOULD instead of MAY
Ge0rG
+1
jonas’
(OPTIONAL = MAY)
susmit88has left
undefinedhas joined
dwd
Specifically, line 222 "It is possible to use an alternative JSON format..." - that always read that way but it might benefit from "additionally".
daniel
+1 on the PR
dwd
And yes, I noted that this raises JRD to a SHOULD, I assumed that was for interoperability reasons?
jonas’
I don’t think we should be nitpicking wording here on this level
dwd
jonas’, And I'm not. Just noting.
jonas’
fair
jonas’
I was tempted to reply, so I felt the need to say that instead :)
jonas’
raising the level for JRD makes sense to me in the web context, so no objections and we can move on
jonas’
4b) PR#961: XEP-0030: Specify that the disco#info feature may not be explicitly set
URL: https://github.com/xsf/xeps/pull/961
Abstract: Since #715 got rejected by council, we may as well drop the requirement to specify this explicitly.
See-Also: https://github.com/xsf/xeps/pull/715
jonas’
assuming my comments in the PR are addressed, I am still left to wonder what this imporoves.✎
jonas’
assuming my comments in the PR are addressed, I am still left to wonder what this improves. ✏
jonas’
and I think we should set the bar for changing normative text of Final XEPs rather high.
paulhas left
dwd
jonas’, The problem this addresses is twofold: Firstly, it's clearly a bit weird to worry about discovering support for service discovery by first making a service discovery request to see if the response includes service discovery.
jonas’
I mean, I see that announcing disco#info is kind of pointless in a disco#info response, but I also don’t see how this fixes any real-world problem.
Zash
Sure, disco#info might be redundant to advertise. But what jonas’ said.
dwd
jonas’, Secondly, ~none of our other XEP examples include this.
dwd
jonas’, So by making this optional, it immediately means our XEPs become conformant.
Zash
dwd, examples? are not normative
daniel
is there a mailing list post or something that describes the problem that this PR is trying to address?
jonas’
I don’t see a problem with the latter. I advocated for blanket-including <!-- ... --> in disco#info examples if one is bothered by them not being complete (which I always felt to be obvious, because if every XEP had full disco#info examples we’d have much longer and more noisy texts for no gain)
jonas’
daniel, not beyond that it’s the author’s follow-up to the rejection of https://github.com/xsf/xeps/pull/715
dwd
daniel, It's trying to document reality. Seems fine by me.
jonas’
to me, it only documents reality of the examples in our documents; that it documents reality on the wire I’d like to see proven first.
dwd
That said, I'm -1 for the reasons jonas’ raiuses on the PR.
paulhas joined
dwd
jonas’, There was lots of discussion around this. Seems most implementations proudly return disco#info, if only to ensure there's at least one feature present.
Ge0rG
I'm on-list
jonas’
-1, unless the author can find real-world issues which are solved by this PR. Specifically, if we don’t require disco#info and then stop requiring at-lesat-one element, it might break strict validators (the existence of which I could endorse given that this is a Final document and at-least-one is a MUST) for no good reason.
Zash
-1, agree with jonas’ & dwd
daniel
yes I agree with jonas’ here as well
dwd
I could go for "disco#info MAY be elided if other features are present" quite comfortably though.
jonas’
as a sidenote, I would very much prefer us being explicit about disco#info replies specifically ✎
jonas’
as a sidenote, I would very much prefer us being explicit about disco#info replies specifically *not* being seen as complete in XEP examples, e.g. by using <!-- ... -->. ✏
Zash
sure
jonas’
because you could turn this the other way ’round too, if you wanted to be pedantic: if '45 does not include pubsub features, is a MUC which announces them non-comformant?
dwd
jonas’, I'd be fine with that as well.
dwd
jonas’, No, you can't.
jonas’
moving on
jonas’
dwd, as devil’s advocate, I find a way to disagree, but I don’t want to waste everyone’s time on this stupid argument of mine :)
We also had this one a few weeks back, but there was discussion about extending the registry without consent from '68. See the second linked mailing list thread.
jonas’
Hence, the validation stuff has been removed from the PR✎
jonas’
Hence, the validation stuff has been removed from the PR and converted into explicit wording, which I think is a reasonable compromise. ✏
jonas’
This would allow us to move forward with extending '68 with validation and then amend the registry entry without breaking anything.
jonas’
so +1
dwd
+1 for this. Noting my misgivings in general about how the Registrar is operating currently.
Zash
+1
jonas’
you mean, not at all? :)
jonas’
I endorse how you rejected a PR of mine to hack into the '45 registry on that grounds (to motivate me to fix the registry), but let other’s PRs pass :)
jonas’
(no offense intended, I am glad that you don’t veto this one)✎
jonas’
(no offense intended or taken, I am glad that you don’t veto this one) ✏
daniel
+1
dwd
Well, in this case the additional entry related closely to the XEP it's in.
jonas’
Ge0rG, anything from you?
daniel
pregaming for the corona party?
jonas’
assuming on-list then
jonas’
(also due to lack of chat states)
jonas’
5) Outstanding Votes
- daniel and Zash are pending on PR#598 (expiring next week) AFAIK (<https://github.com/xsf/xeps/pull/598>)
jonas’
other than that, just the pending ones from Ge0rG from this session
jonas’
6) Date of Next
jonas’
+1w wfm
Zash
+1w wfm
jonas’
thooough I might have a very hard cutoff that day
jonas’
and/or might find during the week that I need a replacement
jonas’
no plans yet, but it’s a date which might cause high-priority plans to appear out of nowhere
Ge0rG
+1 for 0157
Ge0rG
Sorry, got distracted
pep.
woo
jonas’
so if someone is happy to stand in as chair in case I miss the meeting, of course with a prepared agenda, that’d be good
dwd
I can be a stand-in chair.
jonas’
thank you
dwd
If a chair *can* be a stand-in.
stpeter
Please, people, it's not safe to stand in a chair.
jonas’waves to stpeter
daniel
i’m going to be on a train for the first time in forever next wednesday. but I think i'll be able to participate from my phone
jonas’
daniel, wear your mask!
jonas’
okay, we’ll see what we can manage
jonas’
I don’t expect a lot of things to pop up anyways
jonas’
7) AOB
pep.
Yeah wearing a mask is important to participate from a phone
jonas’
anyone got any?
stpeter
BTW https://github.com/xsf/xeps/pull/905 is on my radar screen, I just need to carve out time to look at it more closely.
Zash
Nah
jonas’
stpeter, excellent
jonas’
thanks for that
Zash
stpeter, while you're here, may I poke vrt vcard4? iirc it got into LC but then ???
dwd
I was wondering if we wanted to get a video call together for us, specifically *not* as a Council meeting, but as a more general chat.
stpeter
Do always feel free to poke me (hard it necessary) about PRs.
jonas’
dwd, that sounds like fun
jonas’
I hear the video call stacks around the world got a lot better in the past few months
dwd
Obviously we'll need to spend some time considering what platform to use.
stpeter
Zash: hmm, OK - as I recall, there wasn't strong interest at the time
Zash
FWIW I'll have a lot more time from next week
jonas’
dwd, please no bikeshedding on that
jonas’
if you want it to be a general chat
jonas’
if nobody objects, I’d just suggest some jitsi instance, be it the official one or the ffmuc one
Ge0rG
daniel: your optimism implies that you will be travelling abroad? ;)
dwd
Jitsi is fine by me. I'll sling some time suggestions around the Council list and see if there's interest there.
stpeter
Clearly we should create a list of all possible videoconferencing options and randomly select using the procedures in https://tools.ietf.org/html/rfc3797
jonas’
dwd, that sounds excellent, thank you
jonas’
any other AOB?
stpeter
(But seriously I'd just use Jitsi.)
jonas’
(to clarify, when I say Jitsi, I generally refer to Jitsi Meet)
daniel
Ge0rG, no. just to the other side of country
jonas’
(although I’m aware that’s incorrect)
jonas’
assuming no council-relevant AOB, so
Ge0rG
daniel: I don't think there was significant improvement of mobile network coverage in the last months ;)
jonas’
8) Ite Meeting Est
jonas’
have a splendid evening/remainder of the day everyone
dwd
Thanks jonas’!
Zash
Thanks jonas’, all
Ge0rG
thanks jonas’
stpeter
+1
jonas’
the weather here is amazing if you can repress the nagging thoughts about dryness and climate change
daniel
oh. I had honestly forgotten that this is an issue
dwd
jonas’, BTW, I was looking at Gitlab/Github mirroring; I'd not realised that Gitlab can do that automagically for you these days.
jonas’
dwd, to be honest, we’d hack that in CI jobs
jonas’
to have more control over when a mirror action happens and to have it push based and to be able to constrain the permissions
Zash
what about the locust attack in east africa?
jonas’
(using deploy keys instead of oauth permissions)
Ge0rG
speaking of which: I really liked the gitlab proposal, and I don't care much if gitlab or github is our primary venue, and I'm okay with shutting down the other one altogether after the proof-of-concept phase
jonas’
Ge0rG, thanks for the feedback
jonas’
dwd, the main issue we’re having with the gitlab migration though is the lack of the CLA bot thing... we’ll have to improvise something there, unfortunately.
jonas’
that’s really a bummer
pep.
It's curious really that there's no CLA bot
pep.
That seems to be a common thing to have CLAs (unfortunately?)
jonas’
they don’t have an "app" platform at all
jonas’
AFAIK
jonas’
so that might be why
jonas’
or it’s simply a popularity issue
pep.
maybe
jonas’
I mean there is an implementation, but you have to do AWS Lambda webscale stuff and host it yourself, which I don’t quite appreciate right now
jonas’
-> https://github.com/ScottLogic/gitlab-cla-bot/
pep.
yeah no thanks
jonas’
exactly
jonas’
I mean the API should give you enough info based on that, so maybe someone from the community wants to step up and build a thing *hinthint* *nudgenudge*
jonas’
we could do a basic "hey, we don’t know you yet" comment thing in the CI with appropriate credentials, but it’d still lack any kind of interactiveness
pep.
kinda lost when it comes to searching for this specific issue✎
pep.
kinda lost when it comes to searching for this specific problem ✏
If we can make CI figure out if somebody has signed we can "just" make it terminate early right? We don't actually need to have any API in issues for that I guess?
pep.
Maybe it's just a flag on the issue? dunno if we can set stuff like that