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

Jonas Schäfer jonas at wielicki.name
Sun Jun 14 15:10:54 UTC 2020

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 

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,

   [1]: https://sotecware.net/on-centralisation-of-code-hosting-infrastructure-an-argument.html
-------------- 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/members/attachments/20200614/f85be38f/attachment.sig>

More information about the Members mailing list