Ah, the big movement. Not.
Microsoft baking this may also mean a big step forward, who knows. Regardless, just look at user numbers and there is no alternative, especially if you want to get some drive in international contributions and usage.
I‘m also all in for moving to Github.
Private issues can be solved. We also didn’t have private issues on Forge for years and it worked fine.
We can (and in fact already have) an org on Github with private repos.
Workflow would be: create one private repo for every issue and invite the reporter to this repo as well to verify fixes. This workflow would even be better as what we have now, where communication with the reporter can only happen with mails.
Issue handling on Github is limited, which actually is a big pro for me, because it is simple to understand and use.
Many of the special fields in Redmine can be handled nicely with labels or proper issue templates.
Regarding export or import. Github has a reasonable API to achieve both. If there is a hard requirement to be able to export everything, this can be further investigated. I know at least one service that is capable to backup everything in an Github org.
And of course handling only issues on Github does not make much sense. In the long run we should move everything to one platform and Github is the imho the right choice also for that.
Btw. Github as well has code ownership features with auto adding respective people to pull requests.
We already have a multitude of repositories on Github (some of them essential like Fluid or testing framework), which were moved there because the whole organizational stack, works very nicely and performs very well 99,9% of the time (like any other platform also Github has some outages).
I also work with Gitlab and Bitbucket regularly and both are great platforms as well. But in practice on a daily working basis, Github always performs better, has a much clearer interface and hosts a much larger part of the OSS community.
Regarding concerns about Github as a company:
I respect any personal opinion on that. Github as a company might not be totally perfect in all aspects, but how about other companies we rely on (or kind of use daily) like Slack or Twitter or Google. They all have their flaws. We need to decide whether these flaws are really unacceptable, to not use their (undoubtedly) very useful products. I personally don’t think so. Also, if you use products from these companies, what makes Github unacceptable?
Regarding the concerns Github not being open source: E.g. Slack is neither. We still heavily rely on it and it helps us to get organize better than without it. I love open source and I’m convinced Github does also. They just don’t provide their Software as OSS package. And while I would love to be able to only use OSS all the way, I don’t see how I can achieve that while keeping the level of productivity I have with closed source tools (PHPStorm anyone?)
A minor thing, but quite important for us as PHP project: composer integration with Github is better than with any other platform. It just works, with no major string attached. That is also why we maintain mirrors of our repo on Github and not somewhere else.
But the main argument indeed is:
„(Almost) everybody is on Github and knows how to use this tool“
I fact even the TYPO3 community in larger parts moved there and even the core team maintains 30+ repos there. Our documentation is there.
It is imho about time to make the logical move for our main issue tracker and main repo to move there as well.
Benni (speaking on behalf of the people that WORK with Redmine on a daily basis): „The topic of GitLab is a seperate topic“
GitLab Fans: „Fuck it, we‘ll make it a topic anyways“
Can you please explain the motivation to hijack a thread in such a manner despite our project leader specifically (!) asking not to do so?
Moving to GitHub is a great oppertunity and I think it would also result in an incresead contribution rate. GitHub is the most used open source plattform on the planet and it has proven many times that it is reliable, easy to understand and has a great API / integration to various third party applications. From my point of view, that would be a huge win.
Hmm, yeah @dermattes1 - agreed - this discussion went into a direction I did not expect.
But I’m glad this discussion takes place publically.
My intention with starting this discussion was to investigate IF GitHub Issues would be a replacement to Redmine for TYPO3 Core - we only issues issues with private/public handling, target versions, roadmap and epics currently.
However, I see that there are more things to consider:
- personal preferences / “political” influence and opinion
- self-hosted vs. hosted solution
- MAYBE replacing other areas as well (wiki.typo3.org, git.typo3.org, forger.typo3.org, review.typo3.org)
- TYPO3 community login vs. third-party community login
- Considering other repositories (fluid standalone, docs, t3o, get.typo3.org) where public contributions are allowed
So, this is more a general strategic decision for “where the community” should do contributions in the future. This discussion also helps me to see that this is certainly not limited to “just TYPO3 Core” anymore, I will dispatch this to the TYPO3 association’s board - as I’d really like to see a strategic decision or recommendation for the whole community, and not just one sub-project.
I have experienced in the past that these migrations take a lot of work and effort and months - and even then things are never fully migrated - and some “old places” stay borken as they are. Introducing new ways to contribute for one area also usually lack proper workflows and most of all - guides and education on how to do things the new way.
That is an important point, if not the most important one.
This means any self hosted solution (Gitlab or Phabrocator) isn’t really an option.
And while there is indeed an community on gitlab.org, it isn’t as striving as on Github (i’m fine if i’m proven wrong here with solid numbers).
I‘m also pretty sure that Bitbucket also isn’t an option in that regard.
So the questions rather are:
Are there any blocking concerns that speak against moving to Github?
What do we need to do/achieve for such a step.
The question isn’t:
What are other great tools to host issues and code repositories?
If the question is limited to “let’s host it on our own” or let’s do it with github - then go ahead and start migrating.
I agree with this point: Handling only issues on Github does not make much sense. That’s why I’m not very happy about discussing the move to GitHub when SCM is not taken into account yet. I like to have the full picture before we decide about this.
Two remarks about this:
-
There’s a difference between Slack (which holds important, but still volatile data) and an issue tracker (which holds some of the key know-how of this project). Issue numbers are part of the Git history in TYPO3.CMS.git, and they help me as a developer to understand why this or that has been solved in the way it was done. History is important, and we should make sure that we are able to preserve it forever!
-
The other thing about Github being non-opensource: For me it boils down to the question if we are able to implement missing features or bugfixes, or not. I fear that we will get stuck at one or the other missing feature, and won’t be able to change it, just because Github does not care about our needs…
That’s indeed a very valid point. However, don’t ignore the momentum that GitLab is having right now. Every month they are adding a big amount of really great improvements to their product. Many projects have moved to it already, altough I have to admit that only few of the really big projects were part of that move so far…
(On the other hand, this could be a main reason for considering GitLab more than ever! They have a big interest in winning famous projects for their platform. I am quite sure they would do their very best to help us with the migration…)
Benni, I really think that there needs to be a plan that includes everything, not just issues. I’m ok with moving to Github, Gitlab, whatever. But there are several requirements that need to be fulfilled. These must be clear ahead of any decisions. We should start to put them together…
Some of these must-have requirements, to make a start here:
- Import of existing Forge issues needs to be possible while keeping the same issue uids
- Regular (daily, monthly, tbd.) export of all data needs to be possible, allowing us to move away again from Github/Gitlab/etc. at some point in the future…
- Security team needs to agree on a workflow using the new platform.
- Pricing needs to be checked (private projects are not free, and we do have a few of them…)
- Combination with existing (and future) SCM solution needs to be checked. Are there any blockers with combining A and B?
If the stuff mentioned by Stucki can be solved/ have to be tackled/ are needed, I am totally for moving to GitHub. I am pretty sure, it will enable new people and the collaboration will improve massively. Furthermore, I am looking forward using those awesome issue templates.
So +1 from my side.
I just want to point out that post again, I think some people maybe might not have read carefully enough:
It seems we have already a valid solution to quit forge
It is: up and running NOW, selfhosted, maintained, modern, expandable, feature-rich, already connected to the TYPO3 accounts (LDAP), with import/export functionality, open-source, with a hosted option if needed some day … even with a transparent open source replacement for slack … if we want to move that also some day, and the UI is not that big difference to github, in the end.
Efforts to move along with that pre-existing solution: minimal
(BTW: I use a selfhosted gitlab since years now, and made all the updates without any flaws, and I really like the integrated WebIDE for small issues, when I am on the road and not in front of my dev-machine!)
EDIT: I want to add two things:
- I could live with github too.
- Forge is a pain, just because it is SO SLOW! … So for me, everything which removes forge would be a big step in the future!
In my mind the combination of Redmine and Gerrit sets the bar for new contributers very high. Using GitHub could be a very good solution to make it easier to contribute. It is easier to use, easier to explain, a lot of people used it already and there are more blog post articles out there that explains how it works.
But: Regarding this RFC I would give a strong “-1”. And this is not because I like GitLab or any other tool more but it is because of lacking considerations regarding other solutions:
- the problems with Forge should be defined
- the goals for the TYPO3 infrastructures should be defined (less services and less self-hosted services in my opinion)
- more than one software can be replaced by GitHub (or other) as already mentioned above. The decision to change the ticket system to GitHub would also affect the decision for the other areas (pull requests, wiki, etc.). Therefore, this decision should be made with all aspects in mind.
- alternatives (e.g. GitHub, GitLab, Bitbucket, Phabricator, …) should be compared, already available solutions should be considered
- maybe alternatives could also be evaluated asking the community in form of a survey?
My two cents:
- We need to go away from Forge / Redmine
- I’m a big GitLab fanboy, but I prefer to go to GitHub, because GH is imho the biggest community and the first place everybody is looking for code. GL is on a good way but far away to be the number one.
- GH maybe has not the features we have on Forge, but is there really a need to keep them? Keep it simple for new contributors. Use the issue templates (which is an important feature) and force the reporter to give all needed information in the issue generation and not after 2 or 3 feedback questions.
So, +1 for me for #MovingToGitHub
Regarding the move away from Gerrit, I’d love to know how to force only amended-only commits for PRs.
In GitHub and GitLab you can use the “Squash” feature from Git. That will “squash” all commits from a pull request / merge request into a single commit:
OK, knew this way of merging, but this means moving to GH/GL will change how we handle changes with “having to live” with PR containing tons of follow-up commits until agreeing on the readiness of the PR before squashing and merging.
Not a real problem, just to depict the whole picture.
Does that give a true picture? As far as I have noticed: a lot of developers have their private gitlab installation and know about working with gitlab. what numbers could result if you could count that in?
regarding the offer of David Planella maybe the colaboration of TYPO3 and Gitlab could give benefits to Gitlab and TYPO3 in form of more popularity, more users and more features (as I understand gitlab might implement/open features TYPO3 community misses)
my concerns about changing from forge would be: what about all applications and workflows which now depend on forge. can they be changed or replaced to the new solution?
And what could/ should be changed accordingly?
It may not surprise anyone, but I’m 100% for switching to GitHub. A decision to move can’t please everyone but I think a move to GitHub would please more users than using Forge.
At any time, any maintainer can squash commits into a single commit (but has to use a git client for that). Comparing to Gerrit this is the equivalent of removing all history change sets without removing the discussion of the changes. If you ask me that’s a superior way of working: you can choose that it works exactly like Gerrit with each new commit equaling a new patch set - or you can squash them to clean up even before merging.
On a personal level GitHub is a no-go area. Harassment cases in the past, inflexibility to the needs of paying customers, acquired by Microsoft (they have done weird things with acquired products). Anyway, I’ve promised myself to not donate my personal data to their systems.
A lot of different arguments were presented here. It’s indeed not logical to only move the issues to a platform that offers a complete workflow. So we’re looking for a replacement of the entire workflow.
In that case I would expect that we would look at features, flexibility and support.
Often it is mentioned that GitHub would be the right solution because so many developers already use it. After the mirror on GitHub was made a tool was made or installed to catch any pull requests, convert them to patch sets on gerrit and close the PR with a message. This has been used a few times, but not that often. Which is rather strange as all those millions of developers on GitHub can easily see that there is a TYPO3 repository on GitHub that accepts pull requests.
Looking at the three mentioned online platforms GitHub, Bitbucket and GitLab the last one seems to be the most inviting and co-operative.
In my opinion the whole discussion should not be about moving to product Y. If an alternative for the tools must be found we should first make a list of must haves and nice to haves, and after that investigate which product(s) is/are the best match. A big -1 for “let’s move to product Y” without investigating the requirements and possible matches.