Migrate TYPO3 Core Issues from Forge to GitHub

Archive Discuss Topics
41

I don’t like GitLab, cause it’s slow like hell… (open commits, switch to another menu-point etc.)
and the past has shown that they have not got their system under control (https://www.theregister.co.uk/2017/02/01/gitlab_data_loss/)
and for me, it feels like being downtimes every 2 days.

I like Bitbucket. :slight_smile: but also slow…

So Github has some features for the community / potential new community members:

  • search
  • marketplace
  • and it is much faster

regardless of the platform:
It’s easier for people to find something - and it’s better for the “otto-normal” developer to have all the (the hole TYPO3) stuff in one place.

To forge:
I think many people don’t open a Issue / answer to a ticket cause they don’t know how.
You must know that there is “forge” …
You have an own Account for that.
You have to find the issue List.
Than you have to find that small line “new issue” - which is in a place where you don’t search for a button like that.
I think it is not possible to search directly for a issue, or?!

So yeah please switch to one central place - i am for GitHub at the moment.

42

They took action. So regarding to backups I would trust them more than anyone else. They know what it means if you do backups wrong. Therefore I would say that they are now doing it right after that expirience. No valid argument and only a gut feeling in my opinion.

Can we do a survey on that? Because also further up I could read stuff like: “Everyone has a GitHub account.” or “I never create a GitLab account” or “Everyone has a GitLab acount” or “I never create a GitHub account” – somehow contradicting :wink:

In a survey maybe we can also find out how the current workflow of TYPO3 developers is. I could imagine that it differs from the way how the core is developed.

43

With the already up and running solution (read above, we already have a self-hosted gitlab instance, maintained etc…), you just need your TYPO3 account, which is already connected via LDAP.
But you could open to other login-methods easily if this is wanted, e.g. via auth0: https://docs.gitlab.com/ee/integration/auth0.html
But also “login with Google, Twitter, etc…” is possible, via OmniAuth: https://docs.gitlab.com/ee/integration/omniauth.html
INCLUDING GitHub! So you could basically login with your github account on our selfhosted gitlab, if this is wished and activated.
Therefore IMHO all the “mimimi” about the userbase of GH is at that time just nonsense.

44

I also think this discussion quickly went from: “How to move to GitHub?” into “What are we moving to which service and why?”. So I guess the original question of: “Does a partial move of just the tickets to GitHub makes sense?” I would not agree with.
I personally would prefer a solution without the need for another new account. Regardless of whether or not everyone has a GitHub account, fact would be, that there would be 2 distinct accounts required to take part in the TYPO3 contribution at different places, where there is now only the TYPO3 Account, afaik.
My personal preference as a contributor would be one account to rule them all, I do not care what account, though.

I also thought that the TYPO3 LDAP Account has been created to achieve just that and the move to GitHub would be a step back in that regards

45

I would also like to have the same solution for “all” contributions. Not only the Code of TYPO3, the core, but also for documentation. Right now we link the “Edit me on Github” button to Github :wink: But this should be easy to change for the docs team.

So once the service is defined, might it be GitLab, own GitLab, GitHub, Bitbucket, whatever. This should be changed for the docs, too.

46

This may be a chicken-or-egg type paradox but I imagine that most people who contribute to TYPO3 aren’t new to the fact that we handle merge request on gerrit. I remember once opening a pull request on GitHub and nothing happened - if others had that same experience I doubt they even know this PR-to-gerrit thing exists.

That said, I don’t personally think that lack of PRs on GitHub right now, should be an argument against moving contributions (or as this topic wants to discuss: just issues) to there in the future. If we’re not using that feature we shouldn’t expect it to be common knowledge; rather, we should assume that current common knowledge is “we go directly to Gerrit”. I believe this is also mentioned in various contribution guides.

47

Absolutely, I am in favor of moving issues to GitHub, but only if repositories are also migrated in the future. TYPO3 ecosystem suffers a lot from inconsistencies in the infrastructure (hello semi-secret self-hosted GitLab instance on https://git-t3o.typo3.org). I believe it impact negatively newcomers by confusing them. IMHO minimizing the number of tools should be a priority.

That being said, GitLab could probably also fit our needs. My point is not that one is better than the other, but rather that we should strive to make a single choice, as a community, and stick to it as best as we can.

48

I’m largely in favor of a solution run on own infrastructure, be it the current forge/gerrit-solution or some self-hosted GitLab-environment etc. While for extensions GitHub might be fine, I favor a self-hosted part at least for core, security-issues and what else. Maybe even documentation could be re-integrated at some points (once there is a similar nice “Edit me on our GitLab”-feature maybe).
Having one central typo3.org-account, at least for core-issues and contributions (as well as other tools) is a big plus imho.

49

I believe the opposite is the better thing. The members of the server team have enough to do and if you read about the handling of the last GitHub incident there should be no doubt that this knowledge is hard to beat!

50

I‘m in favor of moving to GH.
Even if only we start with the issues.

Of course I‘d like to see also moving the contribution workflow to GH just because I think that Redmine and Gerrit suck big time.

Both solutions couldn’t manage to improve their UI nor their UX. Only Gitlab is a mentionable alternative.

However, I think in the end something else matters a lot more. TYPO3 is a good product but it still has that touch of being hard to handle, on every level. From contributions over the (luckily improving) source code and architecture to the managing of content itself.

If we want the product and the brand to get a better image we need to regain trust and good developers. While everybody, who is familiar with the ecosystem, has a huge benefit compared to „regular“ developers, we shouldn’t feel to comfortable with that situation because we need a new generation of contributors.

And let‘s face it. There are very cool alternatives to chose from when all that matters is to do OSS work. I personally want contributing to be easy and fun and productive and currently it only works for me because I know my way around gerrit but if I were to choose a second time, TYPO3 wouldn’t get my attention at all.

Ask yourself this: Have you ever stumbled over a project that was on google code? It‘s the links you open and close even before you see anything because the platform sucks. Now ask yourself how others feel when they see forge or gerrit…

Important: This is just my opinion. I will not answer to comments on it. I didn’t mean to hurt/offend anyone when criticizing software. If you have a different opinion, good for you!

51

I do really like gitlab and use it on a daily basis, but for Open Source projects wanting to get more contributors and attracting them, moving the issues to github is a really good starting point.
So, thanks a lot @benni for your proposal. I think this is a huge step forward.

52

Basically making contribution more easy and use tools which are widely used, is the right way.

Regarding the question, if to use Github oder Gitlab, I like to add one additional point of view. For our community development, it could be helpful to require a typo3.org user account as a single entry point. With Gitlab we use this concept via our existing LDAP infrastructure.

With this central account / user profile we can improve our communication and services and also enforce terms of condition.

Stefan Busemann
typo3.org product owner - member of the TYPO3 Association Board

53

I try to cluster and summarize the different areas which we discussed:

  1. 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).

  1. 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.

  1. 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.

  1. 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.

  1. 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.

  1. 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.

54

This topic was automatically closed after 14 days. New replies are no longer allowed.