Migrate TYPO3 Core Issues from Forge to GitHub

Archive Discuss Topics
1

Migrate TYPO3 Core Issues from Forge to GitHub

This is a proposal to migrate all existing issues related to the TYPO3 CMS Core project from forge.typo3.org to TYPO3 GitHub Department · GitHub.

There have been multiple discussions regarding this topic, going back more than 3 years, and I know that people like Helmut Hummel and Mathias Schreiber have been proposing this to me back then, but I didn’t listen to them (“not now”), but I feel this is the right time.

I propose to move all tickets of this project (right now more than 37.000 tickets) to TYPO3 GitHub Department · GitHub while keeping ALL existing Issue IDs, all comments, migrate existing categories to tags.

To be clear: The current workflow using Gerrit as review system is NOT part of this discussion, topic or migration, as this is a separate task, with various other up/downsides. The current plan is to not touch this area around Gerrit and leave that workflow as is.

I do have a small script for testing purposes that acts as a PoC - so it’s not some hypothetical question but rather a valid actual request to do the migration. With this discussion I’d like to find out what downsides are there (or real show stoppers) and if people find obstacles that I didn’t see yet, and we can summarize and see if we can solve this.

As a side note: Forge has a unique issue number for new issues that are installation-wide - so adding a new issue on EXT:gridelements on forge.typo3.org raises the main issue number further, so this is not bound to a project, but used for whole forge, which means that we will have “gaps” (as we currently do) between the existing issue numbers.

Impact

  • Instead of pointing to forge.typo3.org, all tickets should be maintained via GitHub. Everybody contributing to TYPO3 Core needs to have a GitHub account - this is then a new requirement then.
  • All issues are being copied via a script to GitHub, while maintaining issue ID, comments, links, and should be redirected to GitHub
  • Forge will not be mentioned in any Core contribution anywhere anymore
  • Server team needs to be involved in the migration as we need to work with some massive Forge API requests

Possible Migrations

  • People who want to be involved in the migration should contact me, so we can distribute the work load
  • We do a test-run of migrations into a test project / org in GitHub to see what works and what is an issue
  • We choose a timeframe of e.g. 1 day to migrate all tickets, and then disable issues on forge
  • All issues, comments, categories will be migrated
  • Issue numbers that are not part of the project get created on GitHub as empty ticket, and will then be deleted, to maintain the “old” issue number
  • forge.typo3.org gets an info and 301 redirects to GitHub tickets for all existing valid tickets
  • Adapt forger.typo3.org and Gerrit Hooks to work with Forge
  • Adapt Contribution Workflow Guide

Pro

  • We currently use GitHub for various other contribution places (e.g. Fluid Standalone, docs, get.typo3.org), and people are very familiar and comfortable with the way of submitting tickets via GitHub
  • We only use Forge for permissions and issues, nothing else (no wiki) anymore, due to lack of usability (IMHO)
  • Formatting issues is very pleasant!
  • GitHub offers a more flexible API to fetch issues
  • GitHub Issues offers multiple templates for adding issues, add integrations
  • Maintaining forge (Ruby-based) is painful, and is an issue when it comes to customizations and integrations, and I believe (but server team is welcome to take part of this discussion) that this would be a relieve for them as well
  • Main point for me: We go with “standards” (GitHub) instead of a custom solution (forge) for any kind of contributions in the future

Con

  • Not all “custom fields” will be available on GitHub, but this also gives us a chance if we want to keep them (e.g. “percentage done”)
  • I still need to investigate how to achieve “Epic” and subtask issues (haven’t done that)
  • This might be a big change for existing contributors
  • Forge has a nice “roadmap” functionality with the target version summary, haven’t seen that on GitHub yet.
  • Obstacle: We need to see how we can achieve security-related issues and workflows, I will ping Olly on this.

Remarks and notes

The timeline would be - if this change is accepted - to be roughly 8 weeks, I would propose, after having a work group (feel free to leave a comment if you want to help out), to publish a news with all the details and timing information. At least Riccardo (who I talked to before on that) should be on this task force.

At this point of time, this RFC is ONLY about a possibility to move to GitHub, as I have done investigations there, and NOT about moving to GitLab. Moving to GitLab is IMHO a separate discussion, which can be handled, and if the majority wants GitLab.com instead of GitHub, that’s something to be discussed as well, but not really part of this discussion. So please open up a separate discussion proposal about moving issues to GitLab.com, if you desperately want that.

Organizational

Topic Initiator: Benni Mack

2

Forge has a nice “roadmap” functionality with the target version summary, haven’t seen that on GitHub yet.

Isn’t this possible with Milestones, I at least uses it like this.

3

I like the idea to get rid of another tool which is not that so great anymore! So a big plus on that. Just one comment about Epics: This could perfectly done with the Projects, having sprint boards there which would as also allow to remove stuff from forger as well.

However I do see one thing we need to solve which is how to deal with private issues as this is not possible on github. See the feature request from 2013 https://github.com/isaacs/github/issues/37 which is still not addressed.

Another thing which I would like to be changed: If core moves from forge away we should stop forge completly as extensions can use any other tool like github, bitbucket, gitlab, …

4

You don’t want discuss gitlab as alternative in this discussion, but for me this should be discussed.
From my point of view, the issue tracker on gitlab is much more better than the github tracker, also it has some build-in features like kanban-style boards.

Also we should keep in mind the repository question (and integration of the systems).
linking to issues / commits / tags / user etc will work only within the same system (as I know), and if we switch the tracker to github wich is maybe a good idea, I guess the next discussion will be the move of the git repository to github which would be much more pain and has more cons as pros (my opinion).

And another reason to have a look also at gitlab (or other systems): Maybe other systems has features which fit better our requirements!?

So I guess: The topic issue tracker and git repo should not be discussed together, because one decision can/will affect the other one, Just my two cents :slight_smile:

And at least a general +1 to kick out forge from side

5

GitHub got boards too, called Project

6

I’m writing here some spare thoughts that comes in my mind

First of all AFAIK in github it is not possible to have a “mask” where to put information (version, php version, category, etc), but it is possible to pre-format the message. I don’t know if it is possible to “force” people to use this kind of format

A question: are we talking of the free version of github or some “pro” paid version?
I ask because I am wondering what happens in case of a disaster: how much a free tool can guarantee our (precious) data? And how about disservices?

p.s maybe I am going OT, I don’t know how much related: I know that one of our customers uses phabricator (https://en.wikipedia.org/wiki/Phabricator ; https://www.phacility.com/) do someone know it?

7

My only concerns are:

  • Security tickets
  • Custom RSS feeds for private issue filters are not available (I use this for our “field of expertise”)
8

Hey Frank,

my main issue why I didn’t want to open up the full “can of worms” here was that:
a) Discussing getting rid of Gerrit is certainly another level of difficulty (if we want to migrate patchsets etc), same with git.typo3.org - where as
b) Using GitLab (either GitLab.com or self-hosted GitLab) or Phabricator would require somebody™ to evaluate the migration to this platform as well (which is certainly doable, I would say) but also somebody™ to do the job and -if selfhosted- check about the hosting infrastructure.

By no means, I also see benefits with #MovingToGitLab in general (we use GitLab self-hosted for CI reasons in our company). The reason for discussing “Let’s move everything to GitLab” separately could show if we find downsides with GitHub that cannot be overcome (e.g. private issues) in this discussion, but in a separate discussion GitLab solves all needs including the ones in GitHub, that would be something to consider then and get a common concept.

Moving everything (Git Repo + including review/MR/PR concept) is certainly a way bigger job, moving issues was one thing to separate the tasks in general.

Also, currently we have Forge/Gerrit but then docs+Fluid on GitHub but then t3o on self-hosted GitLab seems to be another thing that I (personally) don’t like within the TYPO3 Community, so I try to tackle on at a time… :wink:

9

During a twitter convo an argument came up that I didn’t have in mind before but basically became my go-to argument since then.

My motivation is not “let’s move from Redmine to something else”.
My motivation is “let’s move to GitHub”.

Reason being: Show me the people that actively contribute to TYPO3 that do not have a GitHub Account.
Then show me the people that do not have a bitbucket.org account. I’m one of them.
Show me the people that do not have a GitLab.com account. I’m one of them.

So my main argument is that contributors know how to work with issues on GH.
No special ways to learn things etc.

10

I do not have a GH account. (and I won’t create one either)

11

I personally would opt for gitlab, as gitlab has an open source backgroud, ships with repoditory sync, gerrit integration, jira integration, epics and roadmaps …

Also missing features may be requested via their open tracker, they solved a lot of problems for other open source projects. And I’m not already talking about auto devops …

12

Ohh and i forgot, they support code ownership infos to add people to reviews automatically …

13

I like the idea of moving to GitHub for issues, but only if we intend to move the rest (repo, pr’s) to GitHub as well. If we already think that the features of GH won’t suit us maybe we shouldn’t do the migration to GH. Of course you don’t want to do this in one step, but we should not rush things.
With that said, my personal opinion is that we maybe should not look for a one-to-one replacement for all features, but see what GH can offer us. Like Mattes said, GH is by far the best known system and almost all devs in open source do have an account. Also some parts of the TYPO3 ecosystem already use GH.

So to be short: +1 on moving to GH

And let’s talk next week (on T3CON?) to check if I can be of help if we want to go on with this.

14

As huge Gitlab fanboy i might be a bit biased, however just wanna let you know that we’re running Gitlab on https://git-t3o.typo3.org/ already:

  • fully managed and regularly updated by the Server Team (search for in:#t3o-development about.gitlab.com in Slack)
  • connected to the TYPO3 LDAP already
  • as os project, we could even apply for a Gold/Ultimate license: https://about.gitlab.com/solutions/open-source/
  • i have plenty of experience in running Gitlab and migrating stuff an things at my dayjob for several customers
15

@steiner this … I prefer the gitlab way …this could also bring forge back to life … either on gitlab.com or a local one, the most important pro gitlab argument is the export import function. This includes issues, wiki, and a lot of other resources.

16

Just received a mail from David Planella, Director of Community Relations at Gitlab. As he was not able to join the discussion here due to his missing TYPO3.org account, he sent it to me and @benni directly. I’ll just add it here for everyone else:

Hi,

David from GitLab here. I realize that the OP mentioned the discussion is not about GitLab, but since the conversation has already moved in that direction, I thought I’d post here. Happy to comment in a separate thread if that works better!

Rather than comparing one tool to another, I just wanted to mention that if the TYPO3 community is interested in assessing GitLab for their needs, this is something we can help with.

We’ve worked with other major Open Source projects such as Drupal, Debian, GNOME and freedesktop.org to create initial pilots that would adapt to or improve their workflows. Ultimately the process was always to present them to their own communities to take the final decision on whether they wanted to adopt GitLab.

In very broad terms that’s how the process worked. Along the way, requirements were discussed, issues were filed and features were implemented. In some particular cases features were also moved from the Enterprise Edition (EE) to the Community Edition (CE) as per our commitment to stewardsip of GitLab CE.

This could work similarly if the TYPO3 community is interested. In any case, we’re always very excited to work together with Open Source projects :slight_smile:

I see that T3CON is in Berlin next week. Other than continuing the conversation here, there might also be the possibility to meet with some of the GitLab members based in Berlin if it could be useful.

ll be listening to the conversation here, but feel free to reach out to me directly too.

That’s awesome, by the way. By all means do apply for the Ultimate license for your instance. Also, let us know how GitLab is working for you, we’re always interested in the feedback!

17

I am all in for a complete move to GitHub. Period.

Don’t even think about GitLab or something else self hosted. It is not about the tool, it is about GitHub itself: every developer already has an account, everyone knows how to use it, this is the place where OSS projects grow.

Moving to GitLab just means replacing Gerrit and maybe Forge with another piece of software. Moving to GitHub means to go to where the community is.

18

The community is on gitlab.com as well …

19

I am not talking about the TYPO3 community, but about the OSS community in general.

20

Just saying #MovingToGitlab …