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 _______________________________________________
