[Standards] Evaluating gitlab.com as new location for XEP Editor repositories (xeps+registar)

Jonas Schäfer jonas at wielicki.name
Sun Jun 14 14:31:47 UTC 2020

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 

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 

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:xsf at muc.xmpp.org?join or xmpp:editor at muc.xmpp.org?join rooms (I am 
jonas’), privately via email or XMPP (jonas at 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]: https://gitlab.com/xsf/xeps/-/merge_requests/5
        Click on "Exposed Artifacts" -> "Changed Documents"
        Same here: https://gitlab.com/xsf/xeps/-/merge_requests/4
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.jabber.org/pipermail/standards/attachments/20200614/20fc3d9d/attachment.sig>

More information about the Standards mailing list