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

Dave Cridland dave at cridland.net
Tue Jun 16 21:06:32 UTC 2020


Hey,

I think there is considerable merit in moving to Gitlab - I've found it
impressive to use "in anger" as a product, and the technical abilities that
Jonas outlined below are mouth-wateringly exciting, but also it feels
generally more aligned to our FLOSS-friendly stance as an organisation.

That said, I do understand the caution people are treating such a move with
- it's a big move, and caution seems justified.

Can we use the plan below as a basis to dip a toe in the water in a
reversible fashion, and if it works, ditch Github entirely and place a
holding page there?

I'd personally want to see some kind of definition of success beyond "it
works", but I'm very much open to suggestions there.

Dave.

On Tue, 16 Jun 2020 at 17:58, Jonas Schäfer <jonas at wielicki.name> wrote:

> 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._______________________________________________
> Standards mailing list
> Info: https://mail.jabber.org/mailman/listinfo/standards
> Unsubscribe: Standards-unsubscribe at xmpp.org
> _______________________________________________
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/standards/attachments/20200616/1dfbf15f/attachment-0001.html>


More information about the Standards mailing list