Ge0rGThere is no agenda yet, so I'd like to bring up for vote:
Link Mauvehas left
Ge0rGI even started typing an agenda mail, but then I wasn't able to resist the urge to call it "Twin Towers Edition" and thus I quickly deleted the draft
dwdYou should have written it. I only just noticed it's Wednesday.
jonas’time is tricky
Ge0rGdwd: it would've been biased.
Ge0rGdwd: the time. It is.
KevHere, we are.
dwd1) Roll Call.
Link Mauvehas joined
Link MauveHi, I’m here!
dwdPresumably that's a full house then.
Link MauveJust on time I see. ^^'
dwd2) Agenda Bashing
dwdGiven I didn't notice it was Wednesday, I've not managed one at all, sorry.
KevWe've certainly got fastening on it.
dwdI see one announced ProtoXEP, and one merged but not yet announced, is that right?
dwdPlus the two github PRs above.
jonas’the merged one isn’t built yet, thus not announced
dwdOK, sounds good. So three things.
dwd3) Items for a vote.
dwda) Proposed XMPP Extension: Message Fastening
Ge0rGThis is clearly duplication of existing work.
Ge0rGThe author should collaborate with the authors of Attaching.
jonas’it *is* duplicating existing work, and I find the remarks on the mailing list on lack of examples on how this helps with magic MAM relevant
Ge0rGThere *is* merit in requiring to re-think magic MAM in this context, but maybe Council will be confident enough in this wire format to bear whatever magic MAM will require?
dwdWhat is the actual distinction between this and XEP-0367?
Kevdwd: Council decided last week that they'd rather a new protoXEP was submitted/accepted than 367 updated. As you'll remember.
jonas’something about the <external/> stuff doesn’t sit right with me either, and I’d like to see a practical motivation for it
KevDuring our discussion of whether it should be a new XEP, or an update to 367
jonas’(FWIW, I’m not strictly arguing for rejecting this because of dup)
dwdKev, Sure. But what is the difference between this as '376 beyond "it's in a different document"?✎
dwdKev, Sure. But what is the difference between this as '367 beyond "it's in a different document"? ✏
jonas’the lack of fastenings to fastenings seems like an unnecessary restriction to me
Kevdwd: Mostly the external stuff, the replacing, and the removing that I need to push once it's accepted.
Link MauveI haven’t had the time to read this protoxep entirely yet, I just skimmed through it, but indeed that sounds like it would restrict future usecases we don’t know about yet.
KevAs I've said before, it would fit well into 367 as long as we're happy to update 367 with it.
Link MauveSuch as for instance a fictional external approval for an edit.
KevLink Mauve: Yes, deliberately. Better, in this case, to restrict now and loosen later, than to end up with confusion where we didn't specify the use cases that we didn't anticipate properly.
Ge0rGso maybe the question for Council should be:
1) bury 0367, accept Fastening
2) Merge Fastening into 0367
3) Have both in parallel
Link MauveKev, we’ve had that in the past with 0308, where devs mostly ignored the “last” message restriction, and instead allowed to correct any without further negociation.
dwdI mean, I'm basically fine with the document in isolation. But my impression was that XEP-0367 was unsuited to, for example, reactions. But fastening seems essentially similar to '367, so I'm wondering what fastening gains us that '367 does not.
Link MauveBut fair enough.
Kevdwd: This started because we were told that Sam (as author) did not want 367 used for reactions.
Ge0rGdwd: 0367 is well suitable for reactions, give or take some minor business ruls
jonas’dwd, the only thing which made '367 "unsuitable" was that folks had the strong opinion that reactions are not attachments
KevThe initial plan was to just update 367
KevThen last week I asked for a clear direction from Council as to whether to update 367 or publish something new because I did not want discussions about what the right thing to do was *after* I did the work. We concluded 'publish a new XEP'. Here we are.
KevWe can, of course, go with Sam's offer of adding me as an author of 367 and having at it that way. I'll just be really annoyed by Council's policy flip.
jonas’Kev, I think there was an expectation that your proposal would go further beyond what '367 has
jonas’but I may be wrong
Ge0rGI'd be fully okay with burying 0367 and removing Fastening to New Attaching with a new number
dwdWell, I'm for publishing it, but clearly both '367 and this cannot go on to Draft.
dwdI was just expecting something significantly different from Attaching, I suppose.
KevFTR, I do *not* think 367 is fundamentally unsuited for this, or that fastening is revolutionarily different to 367. I was Just Following Orders.
dwdKev, I think that's somewhat unfair, given that you did insist on having orders to follow.
dwdBut let's vote on this:
dwdAnyone want to vote?
jonas’uh, I was expecting you’d spell something out ;)
jonas’I’m +1 on this
jonas’we can develop this further in Experimental
Ge0rGdwd: in case we do want to merge Fastening into 0367, wouldn't assigning a new number block us from that?
Ge0rGBut yeah, let's make some progress. +1
KevGe0rG: I believe if we wanted to C-A, C-C, ->367, C-V, we could.
jonas’Ge0rG, we can (have Kev) retract Fastening at any time
KevAlthough if that's our intention, we could probably just -1 this now and do it immediately.
Ge0rGjonas’: with Kev following orders, I agree
Link MauveKev, if we want to have only one, and the three 0367 authors are fine with that, it would better be.
Ge0rGfor the protocol, I don't have a strong opinion on that, so we shoud do whatever is good to stabilize fastachments.
dwdI'm +1, just to get progress.
KevLink Mauve: Technically, the 367 authors don't need to be, but yeah.
Link MauveKev, for an experimental one?
KevIndeed. It's the XSF's, Council get to do what they want, pretty much.
KevIt doesn't belong to the Authors.
jonas’Link Mauve, we can always remove them as authors :)
Link MauveI don’t mind having a new number and retracting the 0367 afterwards, or merging it into 0367, so I’m +1 on this too; numbers are cheap.
KevI'm +0 :)
dwdIndeed, XEPs belong to the XSF, but only once adopted and given a number.
Ge0rGso everybody voted now?
dwdI believe so - 4*(+1) +0
KevYes, 4*+1, 1*+0
dwdOK, moving on.
dwdThat's just adding an example of something that should be rejected.
dwdWhich looks good to me. +1
Ge0rGI wasn't sure about the Shakesperean English.
Link Mauve+1 too.
Ge0rGMaybe one of the Brexiters can spellcheck that.
jonas’> Merge made by the 'recursive' strategy.
jonas’> [master 0fbb008] Accept inbox/fasten.xml as XEP-0422
Link MauveShould we have a new CSS class for examples with a red background, to be certain no one will blindly copy this example?
Ge0rGI still have the same AOBs as the last three times.
dwdGe0rG, Yeah. I know.
Ge0rGKev, dwd: did you vote on https://xmpp.org/extensions/inbox/cs-2020.html yet?
dwdI'll try to ensure that with an Agenda and a bit of planning, we allocate more time for these next week.
dwdOh, I thought I had but I had not. There's also others expiring today.
KevI don't think I have anything expiring today. I do have stuff expiring next week.
dwdYes, they expire next week, sorry. I'm a mess today.
dwdProposed XMPP Extension: XMPP Compliance Suites 2020 - https://xmpp.org/extensions/inbox/cs-2020.html
Dave: [on-list] (need time to look at this)
Georg: +1 (obviously)
Jonas: +1 (we can discuss details in Experimental)
PR #812 - XEP-0084: Bump bytes datatype from unsignedShort to unsignedInteger - https://github.com/xsf/xeps/pull/812
Dave: +1 (just rectifies an error in the XML schema)
Kev: [on-list] (default to +1, unless I think of a reason later)
dwdI'll vote +1 on cs-2020. Nothing we can't fix in Experimental, let's get the ball rolling on it.
dwdAnyway, let's call it a day now. See most of you next week.
Link MauveI’m also +1 on both.
KevI'm +0. I don't see anything particularly wrong with it, other than that I want to break the cycle of yearly compliance suites.
dwd7) Ite, Meeting Est.
Link MauveKev, did you have the meeting about it yet?
Link MauveOk. :(
Ge0rGThere is a Council re-election soon, and I'm very sure it will mess up our ability to Last-Call a XEP.
Ge0rGAnd I want 2020 to be finished before 2019 ends.
Link MauveI also want to make it a lot more marketing-oriented.
Link Mauvesonny, ↑
Ge0rGLink Mauve: feel free to PR'ovide better text
Link MauveGe0rG, it’s not necessarily better text, but more like make noise around it, or rename it from Compliance Suite 2020 to something like XMPP 2020 with logos and a testsuite and other not-really-realistic things for the end of 2019 yet.
danielLink Mauve, does that include tweeting about it every 5 minutes?
Ge0rGLink Mauve: all those goals are worthy.
jonas’Ge0rG, any chance you can drop a vote on #812 right now?
jonas’I’m working on a bunch of merges and yours is the last missing
Link Mauvedaniel, I hope not.
danieli think the name doesn’t really matter. but making it more widely know is certainly a good thing
danielnot just for marketing but also simply to give developers a helping hand
danielbut we've also done an ok job with that before
danieli can still be improved obviously. but it's not that we were totally terrible about that
danielreminder about the blog post where someone ranted about activitypub and how bad it is and said that activity pub needed something like the compliance suite that xmpp has
danieland that was someone from outside the xmpp community
Link MauveWas it Stéphane Bortzmeyer?
sonnyLink Mauve and I talked about it today, something like turning complicance suite as an annual XMPP version release, much like the ECMAScript standard
Link MauveHe’s a very well-known protocols guy.
> Ge0rG, any chance you can drop a vote on #812 right now?
danieldon't recal. no it was an activity pub person i think
danieljust saying all that because sometimes with all the internal criticism we fail to see what we actually did right
Link MauveIndeed. :)
sonnyfor clarity I really like the work around complicance suites, just thinking about an evolution
Link Mauvesonny, as Ge0rG said, PR’oviding better text or doing things around it would be super cool. :)