XSF Discussion - 2020-11-28

Isn't it a bit weird for http upload to use iq type=get?

Depending on implementation, this may mutate state (quotas and such) on the server.

it’s to cancel out the type=set in MAM

Hah

Does anyone know what's going on with FOSDEM this year?

There was a call for devrooms, did the rtc room get applied for? Announcement of accepted rooms is overdue according to the last timeline they posted on fosdem.org

Wasn’t it planned to be online? That is, devrooms would be a stream, possibly with an associated chat room.

Yes

Application process much the same though

Ok.

It is possible to validate/merge this XEP-0384 PR in a 0.3.1 version? - https://github.com/xsf/xeps/pull/894 It will be clear to all. Thanks in advance.

Neustradamus: that was all fixed a long time ago, read the comments on that PR. It's long out of date.

SamWhited: Where? The problem is that 0.4.0 OMEMO breaks current 0.3.0 OMEMO clients.

Neustradamus: the spec is long past that; there is no place to merge that PR. I'm not sure what you're even asking.

It's on like 0.7.0 now. We can't go back and re-release an old version.

It is possible to add a 0.3.1 without break :)

How?

The PR and the commit is already done

Where will you merge that PR? The branch has diverged significantly. 0.3.0 isn't a published version anymore.

The solution, better than nothing: Duplication of https://github.com/xsf/xep-attic/blob/master/content/xep-0384-0.3.0.html to https://github.com/xsf/xep-attic/blob/master/content/xep-0384-0.3.1.html with the little change from Anu. And we can insert the 0.3.1 revision part (at the good place - between 0.3.0 and 0.4.0) in 0.4.0 / 0.5.0 / 0.6.0 / 0.7.0 files. And of course the revision part must be added in master without problem: - https://github.com/xsf/xeps/blob/master/xep-0384.xml

ooh, you're wanting a new thing in the attic? I don't think that's a part of the XSF publication process and I don't know where that would even go in our Git history.

Sorry, it's just too late for that.

Maybe the XSF can see for this missing part, and accept it. I recall that this change will not break other versions, there is only a revision note in more.

I'm not sure what to tell you. Even if we put a version in the attic for some reason (which would be meaningless and do nothing) there is nowhere to put it in git.

A duplication of https://github.com/xsf/xep-attic/blob/master/content/xep-0384-0.3.0.html to 0.3.1 with Anu changes The block must be added in master in https://github.com/xsf/xeps/blob/master/xep-0384.xml between 0.3.0/0.4.0. <revision> <version>0.3.1</version> <date>2020-03-05</date> <initials>ap</initials> <remark>Specify the size of the GCM iv to be 12 bytes.</remark> </revision> And it must be added in xep-attic for 0.4.0/0.5.0/0.6.0/0.7.0 files There is no break.

I have already spoken previously for date problem of publication...

And we can see for example here: - https://github.com/python/peps/blob/master/pep-0002.txt "Created:" section "Post-History:" section

That would be extremely confusing because a version block would just appear in master, a new document would appear in the attic, but there wouldn't be any corresponding version in the git history.

That is a python pep, not an XEP, I don't know how the Python community does things, but it's not necessarily the same as how the XMPP community does things. You have already had it explained to you by others why you were wrong about the date of publication problem before.

Yes I know, but it is the solution.

It's not worth talking about it anymore. This is not a solution, I'm sorry. Maybe someone else will be able to convince you or will tell me I'm wrong.

This problem has been done by XSF, XSF must to find the solution. I recall, the PR was here before the 0.4.0.

The PR was there before 0.4.0 and the responsible author decided to not accept it. The reason is even stated in a comment to the PR

The problem you are talking about is a single client implementation deciding to be incompatible with the status quo of an experimental XEP (experimental = not for production). This is not an issue of the XSF.

I feel like this is what you get when you rush things.

And OMEMO seems really rushed, and everyone pushing for it to be implemented by everyone contributed to that.

Now for more appropriate saturday night issues, should I watch a movie or go to sleep?

Zash, depends on the movie

Depends on the sleep-deprivedness.

Was just typing that exact thing :)

SamWhited: At the same time, I specify you that it is same for BitTorrent, example: https://github.com/bittorrent/bittorrent.org/blob/master/beps/bep_0005.rst :)

Neustradamus: that is also not the XSF. Their process is not ours. Also that link is meaningless and tells me nothing. I don't even understand what you're trying to convince us of by pointing us at other peoples documents.

We can improve the system :)

This would not be an improvement, it would ruin our versioning.

This is an experimental XEP that has moved on a long time ago, please let it go. If you want versioning to happen differently, you need to propose something to the board, not just send random links. I don't know what bittorrents versioning is like and that link you sent doesn't tell me so it's not very helpful.