28 ms·

KDE is adopting GitLab

442 points by severine 7y ago

wodenokoto 7y ago
With such an announcement, I always become curious about what they are moving away from.
- przmk 7y ago
  They are currently on Phabricator if I'm not mistaken. https://phabricator.kde.org/ https://phabricator.kde.org/ While it has plenty of features, it's not as user-friendly to use as Github or Gitlab. It can also be confusing at times. I'm glad they're moving to Gitlab and I hope it'll bring some new contributors.
  - pas 7y ago
    I think they also have a Bugzilla, and hopefully they'll move away from that too. (Not because bugzilla is bad, it's just oldschool and makes no sense to keep issue tracking separate.)
    - q3k 7y ago
      > I think they also have a Bugzilla, and hopefully they'll move away from that too. (Not because bugzilla is bad, it's just oldschool and makes no sense to keep issue tracking separate.) It does, IMO. Bug tracker categories rarely correspond cleanly to code repositories. And if you have large repositories then GH/GL issue tracking just gets unwieldy.
    - boudewijnrempt 7y ago
      We won't, as far as I'm concerned, being the maintainer of Krita, the KDE project that gets most bug reports per year. Gitlab's issues feature just isn't powerful enough to be more than a developer's task list. Since it's completely label based, it's hell to use when you've got bug reports coming in from non-contributors. Even classifying issues by OS needs to be done through labels... Just take a look at https://gitlab.gnome.org/GNOME/gimp/issues https://gitlab.gnome.org/GNOME/gimp/issues. I'd prefer to spend time triaging my bugs, instead of labelling them. Plus, it's good to have a gap between user-generated bug reports and developer tasks.
      - brodock 7y ago
        Did you know you can enable Bugzilla integration on your project? Take a look at 'Project Settings' > 'Integrations'. AFAIK It will display the "Issues" link but will redirect you to bugzilla, and some other UI integrations.
        ognarb 7y ago
        We already have an integration feature with Bugzilla using git hooks and some keyword in the commit message. This feature looks interesting, but this feature is sadly only available in enterprise edition. This is my problem currently with the move from Phabricator to Gitlab, we are losing tons of features: review approval, meta project (documentation, visual design group, promo, website, ...), mockups, meta tasks and more. And those features exist but only in the enterprise edition, that is not open source.
  - benreesman 7y ago
    Phabricator is pretty good. I haven’t built serious software using Gitlab, but I have using both Github and Phabricator in various mixtures, and I think there’s a credible case that the world needs more Phabricator. YMMV.
    - deleted 7y ago
      [deleted]
    - zanny 7y ago
      Having contributed to KDE over the years and using the Phabricator in that time the main pain point with it for something like KDE is twofold - 1. it doesn't support the merge request workflow which a lot of would-be contributors would rather have than generating a massive patchset for a feature from a local tree, and 2. the lack of project isolation (having top level issues / commits / etc and second level repo selection vs top level repo that has issues / commits / etc). I always felt like the second point is what really turns potential contributors off from Phabricator because there is no one "page" in it for a specific project, and unlike a lot of would-be good Phabricator use case KDE hosts all kinds of software with no relation to one another. Having them all occurring in a global issue namespace which is basically just tagged per-project and having to go through several directories to find the same project in different Phabricator applications is just a burden at that point.
  - albertzeyer 7y ago
    Are there more details on why they specifically have chosen to move? Maybe there were some discussions in some public mailing lists?
    - pestaa 7y ago
      I found this exploration ticket from a year ago: https://gitlab.com/gitlab-org/gitlab-foss/issues/53206 https://gitlab.com/gitlab-org/gitlab-foss/issues/53206 Nothing on the mailing lists as far as I can tell.
    - boudewijnrempt 7y ago
      Two things: * Development and maintenance of Phabricator has slowed down a lot. * People were claiming phabricator was old-fashioned and confusing and hoping a merge-request based workflow would be more inviting I'm the maintainer of one of the test projects that moved to our gitlab instance, and it's mostly fine, we're missing things in the merge request workflow, but have papered around that with labels (https://invent.kde.org/kde/krita/merge_requests https://invent.kde.org/kde/krita/merge_requests), but we're still using phabricator for task management because it's so powerful for that that we cannot move that part of our workflow to gitlab yet.
    - dplanella 7y ago
      > Are there more details on why they specifically have chosen to move? From the conversations with the KDE team (they might chime in with more context), the main goals were: - More accessible infrastructure for contributors - Code review integration with git - Streamlined infrastructure and tooling - Good relationship and open communication channel with upstream (GitLab in this case) https://gitlab.com/gitlab-org/gitlab-foss/issues/53206 https://gitlab.com/gitlab-org/gitlab-foss/issues/53206 > Maybe there were some discussions in some public mailing lists? I believe there were some other threads as well, but for a start, here is one of the discussions on the kde-devel mailing list: https://marc.info/?t=155091510600001&r=1&w=2 https://marc.info/?t=155091510600001&r=1&w=2
  - pyr0hu 7y ago
    Phabricator also recommends a whole different workflow than Github/Gitlab with their PR ones. But tbh the task management part of Phabricator is much-much cleaner just because of their Tag system. But yes, I agree with you, if you use Phab as a code-review or source code hosting platform, it's pretty confusing.
  - sverige 7y ago
    It's possibly also their motive to bring new contributors, since it was recently announced that KDE will be deprecated in the next major version of RHEL.
- deleted 7y ago
  [deleted]
GrayTextIsTruth 7y ago
more consolidation. at least its competition for github. I could see IBM/Redhat acquiring Gitlab at this rate.
- PudgePacket 7y ago
  My bet is on google. There's a _lot_ of kubernetes/gcloud integration going on with gitlab.
  - pnako 7y ago
    Oracle could be a good candidate too. They have a cloud service and from what I can see their development environment is a mix of basic in-house tools, old-school stuff like Hudson and various open-source projects.
  - DocTomoe 7y ago
    That would be a major reason to abandon the Gitlab ship. Google is notorious for killing off projects. Also, Google had a Gitlab/Github-style page until a few years ago, called Google Code. Obviously, they weren't interested on that venue anymore.
    - mschuster91 7y ago
      > Obviously, they weren't interested on that venue anymore. Because Github and Gitlab was eating up the userbase left and right. The utter lack of any progress/development on Google Code itself was the nail in the coffin driving people away.
    - gbersac 7y ago
      Google only kills unsuccessful projects. Gitlab is an obvious successful project.
      - dgellow 7y ago
        Google Reader was clearly successful.
TekMol 7y ago
So far, I am happy only using pure git. If you guys that use GitLab or GitHub or alike would have to switch to pure git - what is the one thing you would miss most?
- adito 7y ago
  On the social side, that would be starring/watching cool project on the platform.
- wereHamster 7y ago
  I'm a happy GitHub user, these things I'd miss from pure git: - Search (across code, issues, pull requests etc) - Issue tracker (~ manage my backlog, write down potential ideas) - Pull requests, review UI around them - GitHub Apps and Actions (~ automation) and integration with third-party tools (auto-deploy changes to zeit.co / netlify / heroku etc). - Security audits (GitHub can send pull requests to bump my dependencies when security vulns are discovered in them) - Ability to contribute without having to fork/clone/push changes (I quite often contribute to projects by editing the code directly through the GitHub website).
  - OJFord 7y ago
    > (I quite often contribute to projects by editing the code directly through the GitHub website) Whenever I do that I get as far as the commit message and, lacking vi and a 72 char marker, commit 'wip', pull down the changes, amend the commit, and wish I'd done the whole thing locally faster and more easily in the first place.
    - technoweenie 7y ago
      I just format the message in my text editor and paste it back into the commit message box before submitting.
    - wereHamster 7y ago
      I've never the GitHub editor/UI to submit non-trivial changes which require more than a few words to describe. I do not need vi to write "Fix a typo in the documentation". Is it you or the project owners who care about the 72 character limit? IME most projects will accept contributions regardless of formatting of the commit message. Most people are just happy about contributions, regardless of source.
chx 7y ago
Drupal and KDE has similarities in the width of contributors. Both ended up with gitlab. Hm :)
- nwellnhof 7y ago
  GNOME as well.
EspadaV9 7y ago
Couldn't see a link in the post but there seems to be an active GitLab instance here[1]. I've only done a few patches with their previous Phabricator flow and it was a very different experience from the usual GitHub/GitLab workflow. I'm really hoping that switching to something more people have experience with increases the number of contributors. [1]: https://invent.kde.org/public/ https://invent.kde.org/public/
- diminish 7y ago
  If open source projects adopt continuous integration, release and security scanning it will make outsider to contributions easier to make it into the live.
  - lultimouomo 7y ago
    If they were using Phabricator they probably already had a solid sistem of CI and code reviewing.
  - that_jojo 7y ago
    In what way? Regardless of whether they're using CI they still have to pull and mainline your change.
    - johannes1234321 7y ago
      It helps to filter out contributions. If CI is broken you send it back to the contributor. Maybe with some guidance. Only if CI passes you take a deeper look. This helps to spend time efficiently. Of course this has the risk that contributors spend much time on making a patch pass all tests and then get it rejected, since maintainers don't like the feature.
      - smudgymcscmudge 7y ago
        It’s also helpful from the other end. As a new contributor, I feel a lot more confident making a PR if there are tests and I can show I didn’t break them.
jchw 7y ago
Congratulations to GitLab and KDE, I think it will work out well for both. GNOME and Freedesktop are both already on their own instances and it’s been pretty good.
- sytse 7y ago
  Thank you! It has been awesome to see GNOME https://gitlab.gnome.org/explore/ https://gitlab.gnome.org/explore/ Freedesktop https://gitlab.freedesktop.org/explore/ https://gitlab.freedesktop.org/explore/ and Debian https://salsa.debian.org/public https://salsa.debian.org/public embrace GitLab and we hope KDE will have a smooth experience. We're also hoping to see them contribute back features to GitLab they need for complex projects, and I think we've already seen a few.
  - rpaik 7y ago
    Another open source project on GitLab is Haskell (https://www.haskell.org/ghc/ https://www.haskell.org/ghc/). Also, this blog was published when Freedesktop announced their move to GitLab (incl. CI): https://www.fooishbar.org/blog/gitlab-fdo-introduction/ https://www.fooishbar.org/blog/gitlab-fdo-introduction/ We actually have a panel with representatives from Freedesktop, GNOME, and KDE at GitLab Commit in London (https://about.gitlab.com/events/commit/#schedule)in https://about.gitlab.com/events/commit/#schedule)in a few weeks discussing their experience with GitLab.
thresh 7y ago
How do people self-hosting gitlab CE for the open-for-all projects fix the spam problem?
- mgbmtl 7y ago
  On a project I contribute to, we ask people to register on our main website, which has a pretty good anti-spam. We do that in part to get to know our contributors more and better engage (after all, we develop a FOSS CRM). Gitlab uses that authentication source as an LDAP server. So far in the past 2 years, we have had only 1 spam merge-request.
deleted 7y ago
[deleted]
deleted 7y ago
[deleted]
InfiniteRand 7y ago
It's good to see Gitlab staying strong, I worry sometimes that if Github has no competition it might turn into a new Sourceforge (which to be fair has cleaned-up its act in the last several years, but only after years of earning enormous amounts of bad will) Granted with Microsoft ownership there's less chance of Github becoming cash desperate, but it seems possible if somewhere down the line Microsoft loses active interest and goes on life-support, and Microsoft decides that the property is no longer worth protecting from the arbitrary whims and corporate commercial strategies internally.
stevefan1999 7y ago
I just hope GitLab won't accidentally delete their entire server + codebases ever again

442 points by severine 7y ago

wodenokoto 7y ago

With such an announcement, I always become curious about what they are moving away from.

przmk 7y ago
They are currently on Phabricator if I'm not mistaken. https://phabricator.kde.org/ https://phabricator.kde.org/ While it has plenty of features, it's not as user-friendly to use as Github or Gitlab. It can also be confusing at times. I'm glad they're moving to Gitlab and I hope it'll bring some new contributors.
- pas 7y ago
  I think they also have a Bugzilla, and hopefully they'll move away from that too. (Not because bugzilla is bad, it's just oldschool and makes no sense to keep issue tracking separate.)
  - q3k 7y ago
    > I think they also have a Bugzilla, and hopefully they'll move away from that too. (Not because bugzilla is bad, it's just oldschool and makes no sense to keep issue tracking separate.) It does, IMO. Bug tracker categories rarely correspond cleanly to code repositories. And if you have large repositories then GH/GL issue tracking just gets unwieldy.
  - boudewijnrempt 7y ago
    We won't, as far as I'm concerned, being the maintainer of Krita, the KDE project that gets most bug reports per year. Gitlab's issues feature just isn't powerful enough to be more than a developer's task list. Since it's completely label based, it's hell to use when you've got bug reports coming in from non-contributors. Even classifying issues by OS needs to be done through labels... Just take a look at https://gitlab.gnome.org/GNOME/gimp/issues https://gitlab.gnome.org/GNOME/gimp/issues. I'd prefer to spend time triaging my bugs, instead of labelling them. Plus, it's good to have a gap between user-generated bug reports and developer tasks.
    - brodock 7y ago
      Did you know you can enable Bugzilla integration on your project? Take a look at 'Project Settings' > 'Integrations'. AFAIK It will display the "Issues" link but will redirect you to bugzilla, and some other UI integrations.
      - ognarb 7y ago
        We already have an integration feature with Bugzilla using git hooks and some keyword in the commit message. This feature looks interesting, but this feature is sadly only available in enterprise edition. This is my problem currently with the move from Phabricator to Gitlab, we are losing tons of features: review approval, meta project (documentation, visual design group, promo, website, ...), mockups, meta tasks and more. And those features exist but only in the enterprise edition, that is not open source.
- benreesman 7y ago
  Phabricator is pretty good. I haven’t built serious software using Gitlab, but I have using both Github and Phabricator in various mixtures, and I think there’s a credible case that the world needs more Phabricator. YMMV.
  - deleted 7y ago
    [deleted]
  - zanny 7y ago
    Having contributed to KDE over the years and using the Phabricator in that time the main pain point with it for something like KDE is twofold - 1. it doesn't support the merge request workflow which a lot of would-be contributors would rather have than generating a massive patchset for a feature from a local tree, and 2. the lack of project isolation (having top level issues / commits / etc and second level repo selection vs top level repo that has issues / commits / etc). I always felt like the second point is what really turns potential contributors off from Phabricator because there is no one "page" in it for a specific project, and unlike a lot of would-be good Phabricator use case KDE hosts all kinds of software with no relation to one another. Having them all occurring in a global issue namespace which is basically just tagged per-project and having to go through several directories to find the same project in different Phabricator applications is just a burden at that point.
- albertzeyer 7y ago
  Are there more details on why they specifically have chosen to move? Maybe there were some discussions in some public mailing lists?
  - pestaa 7y ago
    I found this exploration ticket from a year ago: https://gitlab.com/gitlab-org/gitlab-foss/issues/53206 https://gitlab.com/gitlab-org/gitlab-foss/issues/53206 Nothing on the mailing lists as far as I can tell.
  - boudewijnrempt 7y ago
    Two things: * Development and maintenance of Phabricator has slowed down a lot. * People were claiming phabricator was old-fashioned and confusing and hoping a merge-request based workflow would be more inviting I'm the maintainer of one of the test projects that moved to our gitlab instance, and it's mostly fine, we're missing things in the merge request workflow, but have papered around that with labels (https://invent.kde.org/kde/krita/merge_requests https://invent.kde.org/kde/krita/merge_requests), but we're still using phabricator for task management because it's so powerful for that that we cannot move that part of our workflow to gitlab yet.
  - dplanella 7y ago
    > Are there more details on why they specifically have chosen to move? From the conversations with the KDE team (they might chime in with more context), the main goals were: - More accessible infrastructure for contributors - Code review integration with git - Streamlined infrastructure and tooling - Good relationship and open communication channel with upstream (GitLab in this case) https://gitlab.com/gitlab-org/gitlab-foss/issues/53206 https://gitlab.com/gitlab-org/gitlab-foss/issues/53206 > Maybe there were some discussions in some public mailing lists? I believe there were some other threads as well, but for a start, here is one of the discussions on the kde-devel mailing list: https://marc.info/?t=155091510600001&r=1&w=2 https://marc.info/?t=155091510600001&r=1&w=2
- pyr0hu 7y ago
  Phabricator also recommends a whole different workflow than Github/Gitlab with their PR ones. But tbh the task management part of Phabricator is much-much cleaner just because of their Tag system. But yes, I agree with you, if you use Phab as a code-review or source code hosting platform, it's pretty confusing.
- sverige 7y ago
  It's possibly also their motive to bring new contributors, since it was recently announced that KDE will be deprecated in the next major version of RHEL.
deleted 7y ago
[deleted]

GrayTextIsTruth 7y ago

more consolidation. at least its competition for github. I could see IBM/Redhat acquiring Gitlab at this rate.

PudgePacket 7y ago
My bet is on google. There's a _lot_ of kubernetes/gcloud integration going on with gitlab.
- pnako 7y ago
  Oracle could be a good candidate too. They have a cloud service and from what I can see their development environment is a mix of basic in-house tools, old-school stuff like Hudson and various open-source projects.
- DocTomoe 7y ago
  That would be a major reason to abandon the Gitlab ship. Google is notorious for killing off projects. Also, Google had a Gitlab/Github-style page until a few years ago, called Google Code. Obviously, they weren't interested on that venue anymore.
  - mschuster91 7y ago
    > Obviously, they weren't interested on that venue anymore. Because Github and Gitlab was eating up the userbase left and right. The utter lack of any progress/development on Google Code itself was the nail in the coffin driving people away.
  - gbersac 7y ago
    Google only kills unsuccessful projects. Gitlab is an obvious successful project.
    - dgellow 7y ago
      Google Reader was clearly successful.

TekMol 7y ago

So far, I am happy only using pure git. If you guys that use GitLab or GitHub or alike would have to switch to pure git - what is the one thing you would miss most?

adito 7y ago
On the social side, that would be starring/watching cool project on the platform.
wereHamster 7y ago
I'm a happy GitHub user, these things I'd miss from pure git: - Search (across code, issues, pull requests etc) - Issue tracker (~ manage my backlog, write down potential ideas) - Pull requests, review UI around them - GitHub Apps and Actions (~ automation) and integration with third-party tools (auto-deploy changes to zeit.co / netlify / heroku etc). - Security audits (GitHub can send pull requests to bump my dependencies when security vulns are discovered in them) - Ability to contribute without having to fork/clone/push changes (I quite often contribute to projects by editing the code directly through the GitHub website).
- OJFord 7y ago
  > (I quite often contribute to projects by editing the code directly through the GitHub website) Whenever I do that I get as far as the commit message and, lacking vi and a 72 char marker, commit 'wip', pull down the changes, amend the commit, and wish I'd done the whole thing locally faster and more easily in the first place.
  - technoweenie 7y ago
    I just format the message in my text editor and paste it back into the commit message box before submitting.
  - wereHamster 7y ago
    I've never the GitHub editor/UI to submit non-trivial changes which require more than a few words to describe. I do not need vi to write "Fix a typo in the documentation". Is it you or the project owners who care about the 72 character limit? IME most projects will accept contributions regardless of formatting of the commit message. Most people are just happy about contributions, regardless of source.

chx 7y ago

Drupal and KDE has similarities in the width of contributors. Both ended up with gitlab. Hm :)

nwellnhof 7y ago
GNOME as well.

EspadaV9 7y ago

Couldn't see a link in the post but there seems to be an active GitLab instance here[1]. I've only done a few patches with their previous Phabricator flow and it was a very different experience from the usual GitHub/GitLab workflow. I'm really hoping that switching to something more people have experience with increases the number of contributors. [1]: https://invent.kde.org/public/ https://invent.kde.org/public/

diminish 7y ago
If open source projects adopt continuous integration, release and security scanning it will make outsider to contributions easier to make it into the live.
- lultimouomo 7y ago
  If they were using Phabricator they probably already had a solid sistem of CI and code reviewing.
- that_jojo 7y ago
  In what way? Regardless of whether they're using CI they still have to pull and mainline your change.
  - johannes1234321 7y ago
    It helps to filter out contributions. If CI is broken you send it back to the contributor. Maybe with some guidance. Only if CI passes you take a deeper look. This helps to spend time efficiently. Of course this has the risk that contributors spend much time on making a patch pass all tests and then get it rejected, since maintainers don't like the feature.
    - smudgymcscmudge 7y ago
      It’s also helpful from the other end. As a new contributor, I feel a lot more confident making a PR if there are tests and I can show I didn’t break them.

jchw 7y ago

Congratulations to GitLab and KDE, I think it will work out well for both. GNOME and Freedesktop are both already on their own instances and it’s been pretty good.

sytse 7y ago
Thank you! It has been awesome to see GNOME https://gitlab.gnome.org/explore/ https://gitlab.gnome.org/explore/ Freedesktop https://gitlab.freedesktop.org/explore/ https://gitlab.freedesktop.org/explore/ and Debian https://salsa.debian.org/public https://salsa.debian.org/public embrace GitLab and we hope KDE will have a smooth experience. We're also hoping to see them contribute back features to GitLab they need for complex projects, and I think we've already seen a few.
- rpaik 7y ago
  Another open source project on GitLab is Haskell (https://www.haskell.org/ghc/ https://www.haskell.org/ghc/). Also, this blog was published when Freedesktop announced their move to GitLab (incl. CI): https://www.fooishbar.org/blog/gitlab-fdo-introduction/ https://www.fooishbar.org/blog/gitlab-fdo-introduction/ We actually have a panel with representatives from Freedesktop, GNOME, and KDE at GitLab Commit in London (https://about.gitlab.com/events/commit/#schedule)in https://about.gitlab.com/events/commit/#schedule)in a few weeks discussing their experience with GitLab.

thresh 7y ago

How do people self-hosting gitlab CE for the open-for-all projects fix the spam problem?

mgbmtl 7y ago
On a project I contribute to, we ask people to register on our main website, which has a pretty good anti-spam. We do that in part to get to know our contributors more and better engage (after all, we develop a FOSS CRM). Gitlab uses that authentication source as an LDAP server. So far in the past 2 years, we have had only 1 spam merge-request.

deleted 7y ago

[deleted]

deleted 7y ago

[deleted]

InfiniteRand 7y ago

It's good to see Gitlab staying strong, I worry sometimes that if Github has no competition it might turn into a new Sourceforge (which to be fair has cleaned-up its act in the last several years, but only after years of earning enormous amounts of bad will) Granted with Microsoft ownership there's less chance of Github becoming cash desperate, but it seems possible if somewhere down the line Microsoft loses active interest and goes on life-support, and Microsoft decides that the property is no longer worth protecting from the arbitrary whims and corporate commercial strategies internally.

stevefan1999 7y ago

I just hope GitLab won't accidentally delete their entire server + codebases ever again