[Standards] NEW: XEP-0440 (SASL Channel-Binding Type Capability)
Version 0.1.0 of XEP-0440 (SASL Channel-Binding Type Capability) has been released. Abstract: This specification allows servers to annouce their supported SASL channel-binding types to clients. Changelog: Accepted by vote of Council on 2020-05-27. (XEP Editor (jsc)) URL: https://xmpp.org/extensions/xep-0440.html Note: The information in the XEP list at https://xmpp.org/extensions/ is updated by a separate automated process and may be stale at the time this email is sent. The XEP documents linked herein are up-to- date. ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
[Standards] UPDATED: XEP-0390 (Entity Capabilities 2.0)
Version 0.3.1 of XEP-0390 (Entity Capabilities 2.0) has been released. Abstract: This document overhauls the XMPP protocol extension Entity Capabilities (XEP-0115). It defines an XMPP protocol extension for broadcasting and dynamically discovering client, device, or generic entity capabilities. In order to minimize network impact, the transport mechanism is standard XMPP presence broadcast (thus forestalling the need for polling related to service discovery data), the capabilities information can be cached either within a session or across sessions, and the format has been kept as small as possible. Changelog: Add another xml:lang example (fs) URL: https://xmpp.org/extensions/xep-0390.html Note: The information in the XEP list at https://xmpp.org/extensions/ is updated by a separate automated process and may be stale at the time this email is sent. The XEP documents linked herein are up-to- date. ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
[Standards] Evaluating gitlab.com as new location for XEP Editor repositories (xeps+registar)
Dear community members, TL;DR: Due to considerable technical advantages, the Editor team is considering moving the repositories currently hosted at github.com/xsf/xeps adn gitlab.com/xsf/registrar to gitlab.com/xsf. This will reduce delays in processing XEP changes and revive the Registry. Detailed explanation and plan below. Table of Contents 0. Executive Summary 1. What? 2. How does this affect the Editor work? 3. How does this affect the community? 4. What is the timeframe? 5. Questions and Feedback 0. Executive Summary Problem statement: The xeps editing process is very cumbersome and under- automated. The registar process is completely stalled due to problems with the currently-used Docker Hub based build infrastructure and GitHub’s permissions scheme. Solution: By migrating to GitLab.com (free plan), we can automate more parts of the xeps process (Proof-of-Concept already finished). In addition, we can adopt the registrar repository under the same umbrella and revive it, fixing a critical problem in our standards process. 1. What? The Editor team is considering moving the git repositories which back their work from GitHub to GitLab. This affects the xeps and registrar repositories first and foremost. This includes moving the complete build infrastructure which is currently spread out over Travis CI and Docker Hub to GitLab CI. 2. How does this affect the Editor work? The Editors currently do many steps manually due to the inflexibility of the GitHub platform. This includes: - Triggering emission of update emails - Tagging commits with new XEP revisions - Archiving new revisions in the attic - Building the docker images with rendered documents (since Docker Hub is often way too slow) With the GitLab CI pipeline system, I was able to achieve the following automation within much less than 16 hours of work: - Automatic emission of emails upon change acceptance - Automatic archiving of new revisions in the attic - Incremental (and thus much faster) building of the Docker images (less than 5 minutes now, as compared to >1h on Docker Hub) - Automatic attachment of rendered versions of all changed documents on Pull requests (They’re called merge requests on GitLab). Looks like this [1] and is very useful for on-list discussion of proposals. But much more importantly, we are also able to hook up the registrar repository into this process (which was previously blocked due to GitHub’s terribly coarse permission model), which means that we’re likely to be able to maintain the registry in the near future. We anticipate to be able to support things like rendering an htmldiff of changed documents in merge requests as well as automated tagging soon. 3. How does this affect the community? *If* we decide to move to GitLab, the following changes will come, we will stop accepting pull requests for xeps or the registry on GitHub. You can still submit patches or ProtoXEPs via email as usual. The preferred way to submit changes would then be via GitLab. Note that you can log into GitLab using a GitHub account. We expect that the much improved and simpler process on GitLab will cause the delay for processing submissions to be reduced considerably. The restoration of the Registry will allow us to move forward with issues and changes which are blocked on that. 4. What is the timeline? 2020-06-13: First experiments in private on GitLab. 2020-06-14: Today. Informal approval from Board members to proceed with the experiment. We start to process Pull requests on GitHub by piping them manually through GitLab to evaluate the process. You can follow us doing that here: https://gitlab.com/xsf/xeps 2020-06-17: Editor team milestone: If we are unconditionally happy with the GitLab things up to this point, we’ll ask Board to adopt https://gitlab.com/xsf as official XSF resource before moving forward. In case we are not happy by 2020-06-17, we’ll move that milestone by one week. When and if Board approves the use of GitLab in the XSF, we will start archiving and deprecating the GitHub repositories ASAP. We will properly re- import them on GitLab to preserve history of Pull requests and Issues as well as possible and update all references to the GitHub repositories to point to the new location. 5. Questions and Feedback If you have questions and feedback to this plan, you can direct that at me in the xmpp:x...@muc.xmpp.org?join or xmpp:edi...@muc.xmpp.org?join rooms (I am jonas’), privately via email or XMPP (jo...@zombofant.net) or in reply to this email to the list. Please do only send messages to the standards@ list which you consider important for the general standards community public. Note that the currently active Editor team members are very much looking forward to this change and we’re convinced that it will help us a lot to reduce the Editor workload while improving throughput. kind regards, Jonas Schäfer XEP Editor Infrastructure Team member [1
Re: [Standards] Evaluating gitlab.com as new location for XEP Editor repositories (xeps+registar)
What are the technical advantages? Also just in general, I completely disagree. We need to be where the people are, and the people are on GitHub whether we like it or not. Don't split up the repos and make XSF resources even harder to find than they already are, don't make things more complicated than they need to be, and everything will be fine. Please don't do this. —Sam On Sun, Jun 14, 2020, at 10:31, Jonas Schäfer wrote: > Dear community members, > > TL;DR: Due to considerable technical advantages, the Editor team is > considering moving the repositories currently hosted at > github.com/xsf/xeps adn gitlab.com/xsf/registrar to gitlab.com/xsf. > This will reduce delays in processing XEP changes and revive the > Registry. Detailed explanation and plan below. ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Evaluating gitlab.com as new location for XEP Editor repositories (xeps+registar)
Hi Sam, Thank you for your feedback. I hear you. I totally see where you’re coming from. Moving off GitHub, which is, as you say, where the people are, is a thing which needs to be considered carefully. Ultimately, the Board will have to decide (hence also CC to members@). First of all, please let me say that I brought this up purely for technical reasons. I don’t have any horses in this race on whether we’re on GitLab or GitHub, for political or other reasons (I don’t believe much in the GitHub-is- now-microsoft-and-should-be-avoided thing [1] and I think we’re not quite there yet with decentralised or de-monopolised code hosting. So this is truly not it. Though that hype happens to have given us control over gitlab.com/xsf, so there’s that at least.). I’d prefer to let things be with the status quo, even if only because updating all the references will be a pain, if the status quo wasn’t terrible. Originally, this wasn’t about xeps even. This was about the registrar repository, which has been malfunctional since the last major change to the infrastructure back in 2017(?). That is an unacceptable state. We’ve been collaborating with iteam (which also is short on time, mind) to find a solution. As it turns out, the current interaction between Docker Hub and GitHub cannot be replicated without introducing security problems (giving Docker Hub write access to all xsf repositories) due to changes on either side of the APIs involved. In addition, we need a solution which is as simple as possible on our end of things, which means ideally that it works with just a docker pull && docker run. Thus, I’ve pondered other options. GitLab CI has the massive advantage of being tightly integrated with the GitLab platform. I was able to set up the registry and xep builds within just an hour or two and have been improving on them since then, giving us automated emailing and archiving. It also seems to be faster on average than the average Docker Hub build, which is good for editor tiredness. Please see the original email for notes on which immediate advantages we gain from what I just did this weekend on the editor side of things. > Also just in general, I completely disagree. We need to be where the > people are, and the people are on GitHub whether we like it or not. > Don't split up the repos and make XSF resources even harder to find than > they already are, don't make things more complicated than they need to > be, and everything will be fine. The exodus of editors since the last change to the infrastructure (moving the builds to Docker Hub) makes me think that it is very much not going to be fine. pep. and I are the two people doing most of the day-to-day work in the team (out of the six members we still have left) and it’s still draining. Calls for support have gone (mostly) unanswered. This is fixing the issues in the Editor work you complained about in the past and which, I think, caused you to leave the team. > Please don't do this. I don’t see how we have a choice unless someone finds a way to do all of what I mentioned on GitHub. Or at least the most important parts of that, which would be the automated tagging, archiving and improved build times, and all of that without introducing a security nightmare. The Registrar has been unable to operate for over three years now. Changes have been blocked and rejected because of this. It is not a way we can continue to operate. Sure it would be nice if we could stay at a place where "the people are" (though I think the ability to log in via GitHub makes the hurdle rather small for GitLab.com). That is indeed the thing which makes me most uneasy with this change. However, I’m more uneasy with not having working Editor processes for such a long time and seeing the standards work suffer under it. kind regards, Jonas [1]: https://sotecware.net/on-centralisation-of-code-hosting-infrastructure-an-argument.html signature.asc Description: This is a digitally signed message part. ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Evaluating gitlab.com as new location for XEP Editor repositories (xeps+registar)
Ahh, I see, this is a Docker Hub issue. I completely agree that Docker Hub has not been a success. It is also quite easy to build Docker images with other CI platforms though while remaining on GitHub (ie. I think you already submitted a PR to use a GitLab CI build). I've built Docker images with GitHub actions (my preferred solution), Sourcehut builds (would be my preferred solution, except that it's still very *very* alpha and I'd hate for people to have yet another account just for CI), and GitLab CI in fact (which I was not a fan of but I'm not the one configuring it or having to deal with it for now so that doesn't really matter). Can we not build Docker images with one of those platforms while leaving the actual repo where it is? If so, that seems to be the direction we should go in first. If the board then wants to decide we need to move all the repos again for some other reason, that's fine but this doesn't seem to call for that. —Sam On Sun, Jun 14, 2020, at 11:10, Jonas Schäfer wrote: > Hi Sam, > > Thank you for your feedback. I hear you. I totally see where you’re > coming from. Moving off GitHub, which is, as you say, where the people > are, is a thing which needs to be considered carefully. Ultimately, > the Board will have to decide (hence also CC to members@). > > First of all, please let me say that I brought this up purely for > technical reasons. I don’t have any horses in this race on whether > we’re on GitLab or GitHub, for political or other reasons (I don’t > believe much in the GitHub-is- now-microsoft-and-should-be-avoided > thing [1] and I think we’re not quite there yet with decentralised or > de-monopolised code hosting. So this is truly not it. Though that hype > happens to have given us control over gitlab.com/xsf, so there’s that > at least.). > > I’d prefer to let things be with the status quo, even if only because > updating all the references will be a pain, if the status quo wasn’t > terrible. > > Originally, this wasn’t about xeps even. This was about the registrar > repository, which has been malfunctional since the last major change > to the infrastructure back in 2017(?). That is an unacceptable state. > > We’ve been collaborating with iteam (which also is short on time, > mind) to find a solution. As it turns out, the current interaction > between Docker Hub and GitHub cannot be replicated without introducing > security problems (giving Docker Hub write access to all xsf > repositories) due to changes on either side of the APIs involved. > > In addition, we need a solution which is as simple as possible on our > end of things, which means ideally that it works with just a docker > pull && docker run. > > Thus, I’ve pondered other options. GitLab CI has the massive advantage > of being tightly integrated with the GitLab platform. I was able to > set up the registry and xep builds within just an hour or two and have > been improving on them since then, giving us automated emailing and > archiving. > > It also seems to be faster on average than the average Docker Hub > build, which is good for editor tiredness. Please see the original > email for notes on which immediate advantages we gain from what I just > did this weekend on the editor side of things. > > > > Also just in general, I completely disagree. We need to be where the > > people are, and the people are on GitHub whether we like it or not. > > Don't split up the repos and make XSF resources even harder to find > > than they already are, don't make things more complicated than they > > need to be, and everything will be fine. > > The exodus of editors since the last change to the infrastructure > (moving the builds to Docker Hub) makes me think that it is very much > not going to be fine. pep. and I are the two people doing most of the > day-to-day work in the team (out of the six members we still have > left) and it’s still draining. Calls for support have gone (mostly) > unanswered. > > This is fixing the issues in the Editor work you complained about in > the past and which, I think, caused you to leave the team. > > > > Please don't do this. > > I don’t see how we have a choice unless someone finds a way to do all > of what I mentioned on GitHub. Or at least the most important parts of > that, which would be the automated tagging, archiving and improved > build times, and all of that without introducing a security nightmare. > > The Registrar has been unable to operate for over three years now. > Changes have been blocked and rejected because of this. It is not a > way we can continue to operate. > > Sure it would be nice if we could stay at a place where "the people > are" (though I think the ability to log in via GitHub makes the hurdle > rather small for GitLab.com). That is indeed the thing which makes me > most uneasy with this change. However, I’m more uneasy with not having > working Editor processes for such a long time and seeing the standards > work suffer under it. > > > kind regards, Jonas >
Re: [Standards] Evaluating gitlab.com as new location for XEP Editor repositories (xeps+registar)
On Sonntag, 14. Juni 2020 17:17:44 CEST Sam Whited wrote: > Ahh, I see, this is a Docker Hub issue. I completely agree that Docker > Hub has not been a success. It is also quite easy to build Docker > images with other CI platforms though while remaining on GitHub (ie. I > think you already submitted a PR to use a GitLab CI build). I've built > Docker images with GitHub actions (my preferred solution), Sourcehut > builds (would be my preferred solution, except that it's still very > *very* alpha and I'd hate for people to have yet another account just > for CI), and GitLab CI in fact (which I was not a fan of but I'm not > the one configuring it or having to deal with it for now so that > doesn't really matter). That’s a good suggestion which did not occur to me, thank you. I’ll evaluate if we can integrate GitLab CI with GitHub sufficiently to achieve the goals. This evaluation will at first happen independently of the XSF repositories. kind regards, Jonas signature.asc Description: This is a digitally signed message part. ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
