I'm semi here and might have to disappear suddenly.
susmit88has left
dwd
Afternoon.
Zash
Hello.
Ge0rG
🤔
jonas’
here I am
jonas’
1) Roll Call
daniel
Hi
jonas’
everyone besides me was here already, great :)
jonas’
2) Agenda Bashing
jonas’
seems like no additions
jonas’
3) Editor’s Update
- Calls in Progress
- CFE for XEP-0050 (ends at 2020-06-09)
jonas’
4) Items for a Vote
jonas’
none as far as I can tell
jonas’
5) Outstanding Votes
jonas’
Ge0rG, you have some, do you want to discuss any of them?
Ge0rG
IIRC I still have a week left, right?
pep.
jonas’, what about the 0157 change?
pep.
Are we waiting on something else to put the new revision to a vote?
Ge0rG
I wasn't able to catch up with the ML, sorry
jonas’
pep., is it ready for council?
pep.
Suuuure?
jonas’
ah, I think we should indeed quickly bring the thing about adding validation stuff to the registry to the list
pep.
I mean I'm fine with doing that next week
pep.
Just curious if there's actually something blocking
jonas’
pep., next time, please send such suggestions in reply to the agenda
jonas’
though in this case that should first go to the list
pep.
k
jonas’
Ge0rG, yes, you still have a week left
jonas’
6) Date of Next
jonas’
+1w wfm
Ge0rG
Phew.
Zash
+1w wfm
daniel
+1w wfm
dwd
Can we do +6 days, 23 hours, and 55 minutes? ;-)
Ge0rG
+1w wfm
jonas’
:P
jonas’
7) AOB
Kev
Did my comments about 393 get through to the list? I would have expected *some* response unless they didn't get through, or I'm being shunned :)
jonas’
Kev, they did, I read them, and I don’t think I had anything to add
Kev
Ok.
dwd
Kev, I think I did mention them, didn't I, in my response to larma?
jonas’
though I have to admit that I’m kind of fatigued about this discussion
Ge0rG&
Kev
dwd: Oh. My bad. I missed that somehow.
SamWhited
Kev: I think I lost them in the wall of emails; reading now, sorry.
dwd
Kev, I meant to, anyway. I did quite like the suggestion of a flag to indicate "I know what I'm doing so you can strip the markup".
dwd
Kev, Though that *really* needs a formal grammar, IMHO.
Kev
SamWhited: The short version is that if you include an opt-in then it signals to a client using a screen reader (for example) that it can strip the markup so it can be usefully accessible. Without changing other semantics.
SamWhited
Kev: I see, that is a good point. I'll have to think about how that interacts with things, but that's a fairly convincing argument at first blush
Kev
Which doesn't solve all cases (e.g. clients that do something like 393 without saying so), but significantly helps accessibility for some cases.
jonas’
since the '393 discussion on-list is going quite vividly, I’d prefer to move this out of this meeting
jonas’
we do have things about XEP-0050 to discuss
dwd
Overall, though, I found larma's treatise on it very useful indeed.
jonas’
which I want to treat with priority given the CFE
SamWhited
Yes, sorry, let's take this OOB.
jonas’
7a) The 'execute' Problem of XEP-0050
Kev
Deja vu :)
jonas’
but it’s useful that Kev is around, since he was involved in the previous iteration of this :)
dwd
Kev, ISTR you had a concrete suggestion of what to do here?
Kev
ISTR I did too.
Kev
GOK what it was.
jonas’
Tedd nicely quoted from the minutes from some time, which I’ll quote here:
3) XEP-0050 'execute' Issue
… Kev explains that it's possible to have an illegal state because 'execute' is overloaded in weird ways - there is an execute action, and an execute attribute for setting a default action, but the execute-attribute default action is not the execute action, which may well be invalid. … Dave attempts to clarify that the default for the execute action is 'complete', unless other actions are specified whereby the default is 'next' which may not even be present - Kev confirms.
Kev mentions PR #598 (https://github.com/xsf/xeps/pull/598) as his attempt to address the issue by unifying the execute attribute and action into one, and that everyone should consider carefully whether this solution will break anything.
Kev explains further that currently if execute is set to 'complete' and the execute command is run, it's actually 'next' that's run; and if there is no 'next' action defined, that's obviously a problem. Dave is justifiably mystified.
Dave suggests an alternative solution might be to deprecate the execute action; Kev thinks this could be a better solution.
Peter utters from the shadows that he recently found his marked-up paper copy of XEP-0050 from several years ago - Kev asks whether it fixes this issue - alas, they are mostly editorial notes.
Dave repeats his suggestion of deprecating the execute action, on the basis of unexpected behaviour; Sam agrees this seems like a good solution as multiple people have been confused in a similar way.
jonas’
So looking at the PR, I (editor hat) closed this because it was for the previous council period and nobody cared enough to process it
jonas’
I suggest we re-open the PR and vote on it next week
jonas’
In addition, I’d like to ask Kev (as the owner of the PR) to add a bit of wording around deprecation of the execute action to avoid any pitfalls
Zash
Wishlist: ELI5 this plz
pep.
Zash, 'execute' has weird semantics. burn it!
Kev
pep.: Which 'execute'?
Kev
(Which is the issue)
jonas’
Zash,
- action='execute' is always allowed
- if the @execute is not set, action='execute' is equivalent to action='next'
- if the form specifies a list of actions which does not include next -> undefined behaviour✎
pep.
Kev, I see. Sorry that wasn't helpful :)
Kev
That's remarkably coherent, thanks jonas’.
jonas’
Zash,
- action='execute' is always allowed
- if the @execute is not set, action='execute' is equivalent to action='next'
- if the form specifies a list of allowed actions which does not include next -> undefined behaviour ✏
jonas’
which Kev’s PR addresses in a good way IMO
jonas’
I’d just like to have another paragraph somewhere which hints people at not using 'execute' if it can be avoided
Kev
I would need to re-read it to be sure, and to see how it's different to Dave's suggestion.
jonas’
Kev, I think it’s orthogonal. Your PR states explicitly that no @execute + actions without next = invalid.
Kev
I do remember that this is one of those "Everything is broken, you can't fix it without something being broken" situations.
jonas’
I’d like to have a bit of wording in there which also states "Don’t 'execute', it’s weird"
Kev
I think the odds of me providing that wording at the moment are vanishingly small, I'm afraid.
jonas’
Kev, good to know, I’ll hijack that PR then
jonas’
with my editor powers
jonas’
and then I’ll re-propose it for next week’s council
flow
I wonder why #598 was closed in the first place?
pep.
"jonas’> So looking at the PR, I (editor hat) closed this because it was for the previous council period and nobody cared enough to process it"
Kev
"So looking at the PR, I (editor hat) closed this because it was for the previous council period and nobody cared enough to process it" (Jonas)
jonas’
flow, it was dormant, and I (Editor hat) did a cleanup of stale PRs
jonas’
I think we have a way forward until next week.
jonas’
Any other AOB?
dwd
None from me.
pep.
(Maybe the best would have been to bring it back to council, but I don't think that was a wrong decision anyway, and it's done now :x)
flow
I'd like to point out that there was an alternative suggestion by me in PR #591
flow
I think 598 and 591 are the two options to move forward
jonas’
> council vetoed a few months ago and discussed rewording to make the intention clear.
(from #598)
jonas’
either way, not in this meeting
jonas’
8) Ite Meeting Est
jonas’
thanks everyone
jonas’
s/598/591/, sorry
pep.
hmm, digging through issues: https://lab.louiz.org/poezio/slixmpp/issues/3432 this looks oddly similar?
flow
pep., it does indeed
dwd
jonas’, Thanks!
Zash
The only action I can see anything in Prosody care about is 'cancel'
pep.
I have a MR still waiting for this, but I wasn't sure if it was correct in the first place
flow
Zash, does prosody initiate a lot of ad-hoc commands?
jonas’
flow, at a first glance, 591 has multiple problems:
- It defines previously undefined behaviour, making implementations which were previously neutral non-compliant
- It does not solve the issue for when neither next nor complete are allowed.
Zash
flow, no? why does that matter?
flow
jonas’, 1. is also true for 598
flow
2. I think it states that execute is mapped to next in that case
jonas’
flow, but in a different way
jonas’
moving this to xsf@
flow
I think what Kev said is right, that is one of those "Everything is broken, you can't fix it without something being broken" situations