Hi, On Tue, 2024-06-04 at 11:10 +0200, Maxime Buquet wrote: > No, this only says that this is a much needed feature, whether or not > the > protocol is considered "ready for use in production software" > (whatever that > means[0]) is irrelevant IMO.
Of course there are three kinds: (a) Those that consider the protocol ready for use in production software and thus use in production software (b) Those that consider the protocol not ready for use in production software, but don't care because they want the feature and don't want to fix the protocol before using it in production software (c) Those that consider the protocol not ready for use in production software, but need to implement it for compatibility with other production software, because of those in (a) or (b) I'd say that: (a) should just step up and make sure the protocol is turned stable, if it can't be turned to stable, they might even learn why the protocol is in fact not ready for use in production, so it's good for them if they try to move it further. (b) is just irresponsible behavior. Irresponsible towards your users (by shipping things to them you consider broken yourself) and towards the wider community (by requiring everyone to now deal with what is not ready for production in their production software). (c) is the worst that we have it, but impossible not to have as long as there is (a) and (b). I'd hope we can get rid of (a) and (c) through changes in the process and (b) by education. When I talk about production software, I'm referring to the server and clients that are used by thousands of end-users and that are therefor impossible to ensure are properly updated. And I'm talking exclusively about released production software (whatever that means for the project, aka what they suggest their end-users that want somewhat stable software to use). > Experimental isn't the issue. The thing is that people want features > / > improvements and will implement them, and that's great. There's no > preventing > it. By doing so they should also ready to also do the work to update > their > software whenever the spec gets updated. I never said Experimental is an issue. The problem is also not that people want features that are currently only available in Experimental. The problem is that we don't manage to move specifications from Experimental (or even before that) to Stable before they are so widespread that changes are hardly possible. If you can't experiment with it anymore (because it would break production software), then it shouldn't be in Experimental. > How does one even experiment without implementation? I was referring to production software implementations, not implementations in test software, feature branches or other experimentation places. > And that's how you end up with Pidgin not having MAM or the like for > years. > Because they indeed refuse to implement Experimental specs. MAM should have been Stable for years before it was marked so that everyone has a basis they can develop on. Pidgin is right in saying they don't want to implement something that says "don't ship this to endusers" in it's header. It's just that many others decide to ignore that warning and therefor there is inconsistency in what's supposed to happen with Experimental XEPs. > Life happens, and people working on specs also get hit by buses / > have > other things to take care of. The burden can't be put on just one > person > alone to do the work. It happens but it's rare that council does > something about it. Not sure what you mean. I never said a single person should do a ton of work. I said that if a XEP becomes de-facto stable (because it has widespread production implementations and therefor can't be changed without causing compatibility issues) we should move it to stable. If there is still (backwards-compatible) work to be done for the XEP to be moved to stable and the author can't do it themselves, someone needs to act as a Document Sheppard as outlined in XEP-0001. The process is all defined, we just don't make use of it. > In other words. You can discourage all you want, that won't stop > anybody from > implementing what they need. And I'd rather have people take a half- > baked spec > in Experimental and try to improve on it and report back. They may > release it > however they want. I am wondering why you think it's good they use Experimental in production. Wouldn't it be better if the spec they need is in Stable? The list of items I provided obviously only goes if we do all of them: Move things to Stable faster so that developers don't need to use things from Experimental in production. > Yes it is clear. It's you that don't want to accept that people may > choose to > implement a protocol that will likely break. End-users don't decide what is implemented. If end-users see that the message editing they have in their client stops working from one day to the other (because other clients updated to a new, incompatible revision), they will be unhappy. We previously have worked around this by implementing multiple revisions of the same XEP at the same time. And this is where I question the use of the word Experimental (and the warning to not implement it): We do actually consider those revisions to be somewhat Stable and take care of compatibility with them. It's what client and server developers already do today. We look at old revisions to figure out how something was done in previous revisions if it's needed for compatibility. So apparently that old revision is in fact stable enough for it to be used even after it is replaced by a new revision. > > Your following example with 0384 is only good in that it would have > made > it much more easy to find if there was another XEP number assigned > for > > 0.3.0, as flow and goffi have said (or will say?) in this thread. There's two things that would have improved: a) We can reference and find the version being used due to the different XEP number b) We can tell people in the header that this is in fact ready for use in production as has been shown by a ton of people using it in production. Today XEP-0384 says it's unsuited for production in its header. It probably is not, but even if it is, that's only true for the latest revision. The older revision certain is fit for production. This is not about changing what people implement. This is about our process correctly reflecting what we do in practice. If you just want to rephrase of what Experimental means, we can also do that (making me wonder though what we will need Stable status for). Of course we can just adjust the wording in the header of Experimental XEPs to something like this: > This Standards-Track document is Experimental. Publication as an XMPP Extension Protocol does not imply approval of this proposal by the XMPP Standards Foundation. Experimental status does not imply any encouragement or discouragement to implementations or deployments in production systems. Older revisions of this proposal may be implemented widely, the current revision might be not implemented at all and may be replaced anytime with a newer revisions. Some implementations will consider compatibility with older revisions of this proposal when implementing it, others may not. See [here] for information about implementations in exiting software. With [here] being a link to the data we gathered from DoaP. In this case I would suggest to update the DoaP specification to not point to a single revision when talking about implementation status, but allow to point to multiple revisions (but maybe that's already possible, not sure). Marvin _______________________________________________ Standards mailing list -- [email protected] To unsubscribe send an email to [email protected]
