<div dir="ltr">Hey,<br><div><br></div><div>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.</div><div><br></div><div>That said, I do understand the caution people are treating such a move with - it's a big move, and caution seems justified.</div><div><br></div><div>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?</div><div><br></div><div>I'd personally want to see some kind of definition of success beyond "it works", but I'm very much open to suggestions there.</div><div><br></div><div>Dave.</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, 16 Jun 2020 at 17:58, Jonas Schäfer <<a href="mailto:jonas@wielicki.name" target="_blank">jonas@wielicki.name</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi again,<br>
<br>
Thanks Sam and Kevin for your valuable feedback. I think what you say <br>
definitely has merit.<br>
<br>
In light of that, we came up with a hybrid solution which may be better or <br>
worse. We need input on that.<br>
<br>
- We keep the GitHub xeps (and registar) repositories.<br>
- We create mirror repositories on GitLab.<br>
- We configure a two-way sync between the GitLab and GitHub repositories for <br>
the main branch, but not for pull/merge requests or issues or non-main <br>
branches.<br>
- We disable the issue tracker on GitHub (or GitLab) so that there’s only one <br>
place to report and track issues.<br>
- MRs/PRs will be handled by editors on both platforms (but still with less <br>
work than before), with equal priority<br>
- MRs on GitLab will gain additional features (like HTML-rendered diffs etc.) <br>
for users; this is because we cannot trivially add those features to GitHub <br>
due to lack of support, but they’re cheap to add over there.<br>
- In the mid-term, we move xep-*.xml into a subdirectory so that the README of <br>
the repositories is more accessible and can be augmented with an "end user" <br>
guide more easily.<br>
- xep-attic moves completely over to GitLab for simplicity.<br>
- Thanks to the two-way sync, we can use the advanced GitLab CI features to do <br>
the automagic.<br>
<br>
Assume that we’ll update all relevant documentation to state that "XEP <br>
contributions are accepted on GitLab, GitHub and via email to <br>
<a href="mailto:editor@xmpp.org" target="_blank">editor@xmpp.org</a>". We’ll also update the repository descriptions to indicate <br>
that they are mirrors of each other.<br>
<br>
We would still have to sort out a few legal bits (e.g. around the CLA/IPR <br>
stuff) as well as actually test if this plan is workable on a technical level <br>
in practice. Before we do that work, we’d like to hear from the (rightfully!) <br>
cautious voices about this approach.<br>
<br>
Again, thank you very much for your feedback.<br>
<br>
kind regards,<br>
Jonas<br>
<br>
<br>
P.S.: Consider the timeline from the previous email void. We don’t want to <br>
rush ahead of the community, even though that will further delay the recovery <br>
of the registry. A few weeks won’t matter on this, and we don’t want a half-<br>
baked solution which does more harm than good._______________________________________________<br>
Standards mailing list<br>
Info: <a href="https://mail.jabber.org/mailman/listinfo/standards" rel="noreferrer" target="_blank">https://mail.jabber.org/mailman/listinfo/standards</a><br>
Unsubscribe: <a href="mailto:Standards-unsubscribe@xmpp.org" target="_blank">Standards-unsubscribe@xmpp.org</a><br>
_______________________________________________<br>
</blockquote></div>