In this task we organise the information campaign about KDE's migrations to Gitlab.
- TODO
- Collect raw data
- Talk to sysadmin
- Get numbers
- Total number of KDE Identity accounts: 68,500 accounts
- Total Developer accounts: 2,646 accounts (part of the 68,500, and doesn't include disabled developer accounts)
- Total number of repositories: 1 Subversion repository (containing literally everything), plus 2,450 Git repositories on git.kde.org (plus an additional 390 personal repositories on invent.kde.org) *Users with developer account: About 2640 Source
- Average commits per month: About 5000 per month over the last year (?) Source
- Lines of code: 978622 insertions per month / 429086 deletions (?) Source
- Average Issues per month
- Bugs: 12094 bugs opened, 24363 bugs closed in the last 365 days (1283 wishes opened, 2292 wishes closed) > More than a 1000 bugs opened a month, 2000 closed a month, about 1000 wishes per month, nearly 200 closed per month
- Current contributors: On average, 40 people will contribute code a day to one KDE project or another Source
- Contributors throughout the history of the KDE project
- Repositories: 936 public repositories, according to GitHub
- List of advantages
@ngraham says:
The big reason for moving was the (most likely true) perception that GitLab's workflow was more familiar and usable than Phabricator's. GitLab uses a fork-the-repo-and-put-your-changes-into-a-branch workflow that's more or less identical to GitHub's, and it involves only using raw git commands. By contrast, Phabricator's patch-based workflow requires the use of a command-line tool (arc) that often doesn't work correctly, and it's full of gotchas that in practice require you to know all the raw git commands anyway, defeating the point.
By moving to the fork-and-branch workflow, it was hoped that the bar to contributing would be lowered for the vast assortment of users and developers who are familiar with GitHub.
Another advantage is unifying our infrastructure by moving the git repo hosting and continuous integration to the same all-under-one-roof infrastructure.
A final one that I'm familiar with is that we have a productive working relationship with the GitLab developers and the product is actively developed and maintained, while our relationship with the Phab devs dried up as its development slowed.
@ognarb and @xyquadrat say:
GitLab offers faster feedback to developers about their code, because it integrates a system that allows unit tests (small tests that are written to check the correctness of an isolated bit of code) to be run directly when a developer uploads a patch for review. If there are any issues with the new code that create a wrong test result, the developer can quickly see this.
- Collect media (graphics)
- Write dot story (?)
- Get quotes from Gitlab people
- Get quotes from KDE e.V. board
- Get quotes from KDE community members affected by the change
- Write press release for Akademy announcement
- Write social media posts
- Answer these questions:
- Who are involved in tools decision making and what is the process involved in introducing a new tool to your community?
@neofytosk says:
The following teams were involved in the discussions with Gitlab:
- sysadmin
- e.V. board
- onboarding
Of course the sysadmin here has all the technical know-how and advises the other teams and the community.
In terms of the final decision, the whole community decides together via discussion. The process was/is at follows:- Open discussion on considering the switch
- Approval by KDE community to proceed with testing
- Testing process initiated, led by sysadmin team
- Teams were asked to join and provide feedback
- Requests and feedback was transferred to Gitlab
- Suggestion made to community and discussed
- Final/complete switch currently pending
- What was the most challenging aspect of #movingtoGitLab? How did this compare with other tools in your community?
@neofytosk says:
We can't really describe what we are doing as #movingtoGitLab so much as #adoptingGitLab. It is pretty clear that there are workflows that would break if we made a dry cut move, so many of the older frameworks will have to stay in place and users and projects associated with them will move to GitLab at their own speed, if at all. This will probably take time.
- Challenges with tools, workflow, etc.
@neofytosk says:
The challenges we faced so far included:
- Inertia, as we had rather recently switched to Phabricator and of course people are never good with handling change.
- Breaking current workflows and adopting to new ones.
- Addressing productivity issues we consider as showstoppers
- Negotiating with Gitlab on moving things from Gitlab EE into Gitlab CE.
For the comparison with other tools and a more technical opinion I suggest asking sysadmin, they can probably compare with the switch to phabricator.
@ognarb and @xyquadrat say:
Not all our infrastructure can be unified in GitLab, because we still need binary-factory to rebuild our websites if there are any code changes.
- Can you share your communities’ feedback on GitLab so far?
- Positives & Areas for improvement
- What are your future plans with GitLab? What would you like to see from GitLab in the future?
@neofytosk says:
Moving workflows other than hosting code on Gitlab, like project-management, bug-tracking, general discussions, design reviews, etc.
- How can GitLab community help you as you use GitLab
@neofytosk says:
I would say mostly via support. I am sure we will run into issues sooner or later and we could use all the help we can get in getting our workflows integrated with Gitlab.
- Do your community members contribute to other open source projects? Have they contributed to GitLab?
@neofytosk says:
We definitely have many members contributing to other FOSS projects, like Linux-based distributions, libraries, LibreOffice, Mozilla/Firefox, Wikipedia, to name a few. I have no idea how we can check if KDE people have contributed to Gitlab. Perhaps I can ask during my talk but it might be awkward if noone responds. =)