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

Jonas Schäfer jonas at wielicki.name
Tue Jun 16 16:58:41 UTC 2020


Hi again,

Thanks Sam and Kevin for your valuable feedback. I think what you say 
definitely has merit.

In light of that, we came up with a hybrid solution which may be better or 
worse. We need input on that.

- We keep the GitHub xeps (and registar) repositories.
- We create mirror repositories on GitLab.
- We configure a two-way sync between the GitLab and GitHub repositories for 
the main branch, but not for pull/merge requests or issues or non-main 
branches.
- We disable the issue tracker on GitHub (or GitLab) so that there’s only one 
place to report and track issues.
- MRs/PRs will be handled by editors on both platforms (but still with less 
work than before), with equal priority
- MRs on GitLab will gain additional features (like HTML-rendered diffs etc.) 
for users; this is because we cannot trivially add those features to GitHub 
due to lack of support, but they’re cheap to add over there.
- In the mid-term, we move xep-*.xml into a subdirectory so that the README of 
the repositories is more accessible and can be augmented with an "end user" 
guide more easily.
- xep-attic moves completely over to GitLab for simplicity.
- Thanks to the two-way sync, we can use the advanced GitLab CI features to do 
the automagic.

Assume that we’ll update all relevant documentation to state that "XEP 
contributions are accepted on GitLab, GitHub and via email to 
editor at xmpp.org". We’ll also update the repository descriptions to indicate 
that they are mirrors of each other.

We would still have to sort out a few legal bits (e.g. around the CLA/IPR 
stuff) as well as actually test if this plan is workable on a technical level 
in practice. Before we do that work, we’d like to hear from the (rightfully!) 
cautious voices about this approach.

Again, thank you very much for your feedback.

kind regards,
Jonas


P.S.: Consider the timeline from the previous email void. We don’t want to 
rush ahead of the community, even though that will further delay the recovery 
of the registry. A few weeks won’t matter on this, and we don’t want a half-
baked solution which does more harm than good.
-------------- 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/20200616/806fc93d/attachment.sig>


More information about the Standards mailing list