I try to cluster and summarize the different areas which we discussed:
- Self-hosted vs. GitHub/GitLab.com
This boils down to the question, whether we want to centralize our contributions around TYPO3.org or any other platform that is not self-hosted: namely GitHub.com or GitLab.com. Both of these services offer a possibility so we could put a my.typo3.org “Sign in with GitHub/GitLab” possibility in there to connect a typo3.org account to a different service.
The main observation: Do we want to evolve everything around the “you need a dedicated TYPO3.org account” to add everybody to the TYPO3 universe – or not? Formulating it a bit more drastic: Do we want TYPO3 Core development evolve around TYPO3.org accounts or remove that obstacle for newcomers?
Both approaches have advantages (= which are basically the disadvantages of the others).
GitHub.com vs. GitLab.com
The argument “we go where the community is” IMHO clearly goes to GitHub.com, although GitLab.com has been improving as some OSS projects move to GitLab. Literally ALL of our PHP- and JS-based libraries that TYPO3 includes run on GitHub. None on GitLab AFAIK. Packagist.org integration is optimized for GitHub for a reason - I guess because their statistics tell a similar story, but I can ask the Packagist creators again in case you want to know.
- Enhanced Feature-Set of GitLab vs. GitHub
I personally use GitLab as well for customer projects, and really enjoy much of their CI/CD implementation. But TYPO3 Core development does not need this - and TYPO3 Core will not change this in the next 12 months at all. Christian Kuhn literally spent hundreds of hours to get this setup with Bamboo as it is right now, and I hope we finished this now. Moving to GitLab CI would be possible, but just not important from our PoV right now - plus, Bamboo is hosted with TYPO3 GmbH, so we’d need to check with them.
GitLab self-hosted has obviously more features at hand, but question is, if we are going to use them in TYPO3 Core development.
We can evaluate other features we currently do not use (Boards, Groups, Teams) of course, but that doesn’t seem to be a show stopper now.
Self-hosted brings the burden of having to maintain the system by the community / server team with limited resources these days. So we’d need some more people continuously helping the server team maintaining and improving self-hosted GitLab - but at least there is some knowledge there from Andri.
- Review Process
In ANY option (GitHub.com, GitLab.com, Self-Hosted GitLab) the discussion came up that we could also replace our review system Gerrit with PR/MR concepts. To be honest, I haven’t fully evaluated all consequence fully, so I don’t have a full grasp on the consequences yet. I know that certain changes will become more difficult to review, while I hope that overall contribution rate will increase. I - and I guess no one - cannot foresee this. One thing for sure is that with Gerrit switching the underlying Git Repository to talk to GitHub.com, GitLab.com or Self-Hosted GitLab instead of git.typo3.org is doable with little effort. So this leaves the biggest question mark for me, if we should actually move the reviewing system as well.
- Private repositories / Security-related issues
IF we are going to move to something else than git.typo3.org/Gerrit there will be benefits how security issues are handled. Both Helmut and Olly, involved in core security in the past, have mentioned that. GitHub.com comes with a price tag, the other options don’t.
- Work load to do the actual change and maintenance
I do like the spirit of the discussion here, and it’s good to talk all options out. At the end, there needs to be a decision, and after that, there will be lots of work to be done. Regardless of which option to choose. This is not just done with a “one-time-migration-tool”, but lots of education, docs, refining various things, and that means - man-power from people willing to spend lots of their time to do the change, believing that TYPO3 will benefit from this change in the future years.
There are lots of opinions, but we also need people willing to spend quite a few days dealing with the actual migration, sorting out issues and solving problems, updating docs, setting up infrastructure or talking to GitLab/GitHub, and maintaining the new infrastructure for a decent amount of time. So, now that most of the issues have been addressed, a migration plan should be put into place, to find out how much time it will take to do the change (GitLab/GitHub/GitLab self-hosted) and who would be willing to lead such a working group.
My take - and sole motivation for this discussion - is actually that I truly believe switching to a more widely-known system will increase the visibility, contribution rate, adoption rate of TYPO3 - opening up doors to people that haven’t fallen in love with TYPO3 yet - that’s my mission.