[Standards] MIX progress

Florian Schmaus flo at geekplace.eu
Tue Jul 5 10:28:02 UTC 2016


On 05.07.2016 11:37, Dave Cridland wrote:
> On 5 July 2016 at 10:25, Florian Schmaus <flo at geekplace.eu
> <mailto:flo at geekplace.eu>> wrote:
>     On 05.07.2016 11:05, Dave Cridland wrote:
>     > On 5 July 2016 at 09:51, Florian Schmaus <flo at geekplace.eu <mailto:flo at geekplace.eu>
>     > <mailto:flo at geekplace.eu <mailto:flo at geekplace.eu>>> wrote:
>     >     On 05.07.2016 10:08, Evgeny Khramtsov wrote:
>     >     > Tue, 5 Jul 2016 09:55:53 +0200
>     >     > Florian Schmaus <flo at geekplace.eu <mailto:flo at geekplace.eu> <mailto:flo at geekplace.eu
>     <mailto:flo at geekplace.eu>>> wrote:
>     >     >
>     >     >> I'd also welcome if XEP development, especially for such an important
>     >     >> one like MIX, would be more open.
>     >     >
>     >     > For the record, we already have github XSF repo for that. We can keep
>     >     > development there and tag stable version.
>     >
>     >     So far, the XSF repo is *only* used for submitted XEPs, everything in
>     >     inbox/ is a ProtoXEPs and XEPs with numbers follow the standards track.
>     >     Changes are only made by the XSF Editor Team. It is not used for active
>     >     development of those XEPs, and I think it should be that way.
>     >
>     > I sort of agree. I don't see the harm in forking the repository, and
>     > working in "pull requests" (which are, after all, just branches).
> 
>     That approach would not be visible enough. For one, PRs are not build
>     and made available as rendered HTML somewhere. Granted, this eventually
>     could be changed. But I still think there is a need for a repo for
>     incubating XEPs.
> 
> 
> A different repository is a different repository. PRs are just branches.

Yes.

> You're saying that one change cannot be made because it's not as big as
> the one you want.

No.

>     >     A while ago I suggested establishing an extra repo for incubating XEPs
>     >     and updates to existing XEPs in xsf at . My vision was to make write access
>     >     to that repo easily possible, to have it build via CI, and to publish it
>     >     somewhere (e.g. xmpp.org/lab <http://xmpp.org/lab>
>     <http://xmpp.org/lab>), with the hope
>     >     that this will encourage
>     >     collaboration, improve the quality of ProtoXEPs and kickstart
>     >     experimental implementations. This idea was not received well for some
>     >     reasons I frankly do not understand. We clearly need a place like that.
>     >
>     >
>     > I think that would be an admission of failure of what ought to be a
>     > really simple process for authors. Write XEP. Publish. Rinse. Repeat.
>     > All the way until Draft.
> 
>     I believe the current process is seriously flawed and has never worked
>     as it was envisioned. So yes, it is an admission of failure. But what's
>     wrong with that if the goal is to improve it? People want feedback about
>     their XEPs before they are submitted to the XSF. It is as simple as
>     that. A we as XSF do not provide them with a tool-chain to support them
>     with this venture. Georg Lukas has just recently made the same
>     experience, I made with *every single XEP I wrote*.
> 
> 
> Until a XEP is submitted it's not an XSF effort. That's by definition,
> and it has serious implications on our IPR rules to change that - the
> submission process includes copyright assignment, for example.
> 
> All you're doing is right-shifting the process, and that'll end up with
> us dropping the Draft state because we're going from
> Proto->Experimental->Final. This isn't idle speculation, it's precisely
> what's happened in the IETF.
> 
> Instead, if you think the process is flawed, describe why, and propose
> changes to XEP-0001 - don't try to end-run around it.

We start to talk about two different topics here. One is a repo for
incubating XEPs which has an "powered by XSF" sticker on it. And the
other is about the life-cycle process of XEPs. I think I already
explained substantially why I believe such an incubating XEP repo would
be great.

And about the other process:  Maybe carbons (XEP-0280) is a good
example. It's one of the five XEPs I consider crucial for XMPP's future
(the other one being SM, CSI, MAM, and maybe MIX). It's been in last
call for nearly a year. I've not heard much from the authors. I also saw
no interest from them to progress the XEP. Of course, that's perfectly
fine and I don't blame them. In open standard and open source work,
nobody is obliged to do anything (unless you get paid for it maybe). But
as far as I know, we have no policy how to handle this. And thus, a
critical building block of XMPP technology is in a state of suspense and
makes no progress.

Is carbons the only example? No, we have 8 XEPs in last call. Some of
them for years.

- Florian

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 603 bytes
Desc: OpenPGP digital signature
URL: <http://mail.jabber.org/pipermail/standards/attachments/20160705/789e9635/attachment-0001.sig>


More information about the Standards mailing list