Gitlab migrations informative campaign
Open, Needs TriagePublic

Description

In this task we organise the information campaign about KDE's migrations to Gitlab.

  1. TODO
  2. 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
  3. 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:

  1. Inertia, as we had rather recently switched to Phabricator and of course people are never good with handling change.
  2. Breaking current workflows and adopting to new ones.
  3. Addressing productivity issues we consider as showstoppers
  4. 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. =)

paulb created this task.Jun 17 2019, 12:00 PM
crozbo added a subscriber: crozbo.Jun 17 2019, 12:13 PM
paulb updated the task description. (Show Details)Jun 17 2019, 1:11 PM
paulb updated the task description. (Show Details)
neofytosk added a subscriber: paul.EditedJun 30 2019, 6:56 PM

@paulb is there any update on this? Did David ever respond to @skadinna's email? If not we should probably bump the discussion.

paulb added a comment.Jun 30 2019, 8:34 PM

@paulb is there any update on this? Did David ever respond to @skadinna's email? If not we should probably bump the discussion.

He did not, no.

paulb added a comment.Jul 4 2019, 9:51 AM

@paulb is there any update on this? Did David ever respond to @skadinna's email? If not we should probably bump the discussion.

Talked about this yesterday. @skadinna will ping David, see if we can get this rolling again.

Thanks @skadinna for the reminder email.

We have been informed that due to personal reasons (all good, nothing to worry about!) David will not be able to handle this. He will soon assign someone else to takeover his tasks, I will keep you in the loop once we have more info.

Thank you for the update, Neofytos. I'm wondering if there's anything we can do in the meantime, while we wait. Otherwise it might be all rushed if we get very close to the official announcement date without anything prepared in advance.

paulb updated the task description. (Show Details)Aug 20 2019, 5:29 PM
paulb updated the task description. (Show Details)Aug 22 2019, 10:46 AM
paulb added a comment.EditedAug 23 2019, 5:51 PM

Thank you for the update, Neofytos. I'm wondering if there's anything we can do in the meantime, while we wait. Otherwise it might be all rushed if we get very close to the official announcement date without anything prepared in advance.

We have to start collecting data. The guys from GitLab sent me the following list of things we have to answer:

  • Tell me about your project and your infrastructure requirements (e.g. repo’s, wiki, issue tracking, mailing lists, etc.)

This one would be ALL OF THE ABOVE + workboards. We would need numbers: how many repos, mailing lists, etc.? How many issues to we receive a day/month/whatever?

  • What were some of the reasons for deciding to use/adopt GitLab?

@apol said "familiarity", "simplicity" and "consistency". Maybe a little more detail would be helpful: how is GitLab simpler than Phabricator, for example.

  • Who are involved in tools decision making and what is the process involved in introducing a new tool to your community?
  • What was the most challenging aspect of #movingtoGitLab? How did this compare with other tools in your community?
  • Challenges with tools, workflow, etc.
  • 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?
  • How can GitLab community help you as you use GitLab
  • Do your community members contribute to other open source projects? Have they contributed to GitLab? -

This is for press releases, GitLab events, etc. Can we brainstorm these answers, please?

paulb added a subscriber: apol.Aug 23 2019, 6:14 PM
ngraham added a subscriber: ngraham.EditedAug 23 2019, 9:17 PM

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.

I'm sure others involved in the transition itself can offer more.

paulb added a comment.Aug 23 2019, 9:45 PM

Thanks, @ngraham. That is very helpful.

ognarb added a subscriber: ognarb.Aug 23 2019, 10:32 PM

Another advantage is unifying our infrastructure by moving the git repo hosting and continuous integration to the same all-under-one-roof infrastructure.

This is probably a point that need to be confirmed with the sysadmin. I was told that the websites need to be deployed with binary-factory (see https://invent.kde.org/sysadmin/ci-tooling/merge_requests/17), but it's probably an exception. One of the cool new functionality of the integrated ci is that this allows to run unit test for merge request and this feature can help the devs to review the change faster.

I was told that the websites need to be deployed with binary-factory (see https://invent.kde.org/sysadmin/ci-tooling/merge_requests/17), but it's probably an exception. One of the cool new functionality of the integrated ci is that this allows to run unit test for merge request and this feature can help the devs to review the change faster.

I do not know what either of those two sentences mean. Can you explain in layperson's terms?

Another advantage is unifying our infrastructure by moving the git repo hosting and continuous integration to the same all-under-one-roof infrastructure.

This is probably a point that need to be confirmed with the sysadmin. I was told that the websites need to be deployed with binary-factory (see https://invent.kde.org/sysadmin/ci-tooling/merge_requests/17), but it's probably an exception.

Here Carl points out that currently 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.

One of the cool new functionality of the integrated ci is that this allows to run unit test for merge request and this feature can help the devs to review the change faster.

I'd rewrite this as: 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.

Hopefully that makes it a bit clearer - I still wouldn't include such technical details in an announcement though.

Another advantage is unifying our infrastructure by moving the git repo hosting and continuous integration to the same all-under-one-roof infrastructure.

This is probably a point that need to be confirmed with the sysadmin. I was told that the websites need to be deployed with binary-factory (see https://invent.kde.org/sysadmin/ci-tooling/merge_requests/17), but it's probably an exception.

Here Carl points out that currently 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.

One of the cool new functionality of the integrated ci is that this allows to run unit test for merge request and this feature can help the devs to review the change faster.

I'd rewrite this as: 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.

Hopefully that makes it a bit clearer - I still wouldn't include such technical details in an announcement though.

Please pay attention to the way this idea is presented. Technically Phabricator provides a component which does this (harbormaster). It is not marked as "stable", but it does exist, and I think that sysadmins experimented with it. So it was allowed too.

Please pay attention to the way this idea is presented. Technically Phabricator provides a component which does this (harbormaster). It is not marked as "stable", but it does exist, and I think that sysadmins experimented with it. So it was allowed too.

We are definitely not going to go into this level of detail in a press release, so don't worry.

paulb updated the task description. (Show Details)Aug 30 2019, 7:25 PM
paulb updated the task description. (Show Details)

@xyquadrat suggest looking at this: https://bugs.kde.org/weekly-bug-summary.cgi?tops=20&days=365

and this: https://reports.kde.org/en/projects/kde-community

In the latter, many of the graphs taper off in 2014, so we will still need up-to-date data from elsewhere.

paulb updated the task description. (Show Details)Aug 31 2019, 11:10 AM
paulb updated the task description. (Show Details)Aug 31 2019, 11:29 AM
paulb updated the task description. (Show Details)Aug 31 2019, 11:31 AM
GB_2 updated the task description. (Show Details)Aug 31 2019, 11:55 AM
GB_2 updated the task description. (Show Details)
paulb updated the task description. (Show Details)Aug 31 2019, 3:23 PM
paulb updated the task description. (Show Details)Aug 31 2019, 3:30 PM
paulb updated the task description. (Show Details)Aug 31 2019, 4:24 PM
paulb updated the task description. (Show Details)Sep 1 2019, 11:38 AM
paulb updated the task description. (Show Details)
paulb updated the task description. (Show Details)Sep 3 2019, 5:15 PM
paulb updated the task description. (Show Details)Sep 3 2019, 5:22 PM
paulb updated the task description. (Show Details)Sep 6 2019, 11:22 PM
paulb updated the task description. (Show Details)Oct 6 2019, 10:20 PM
paulb updated the task description. (Show Details)Wed, Oct 30, 10:59 AM

We also participated on panels at GitLab Commit Brooklyn and GitLab Commint London