18 ms·

The KDE community is moving to GitLab

419 points by caution 6y ago

Jonnax 6y ago
It's cool that KDE are using the Community Edition if Gitlab
- jsiepkes 6y ago
  So how do they deal with (what seems to me) basic functionality that the Gitlab community edition is missing? Like for example linking issues as related?
  - sho_hn 6y ago
    We told our friends at GitLab from the start that we would be running the Community Edition, as our policies and principles require. During the eval phase mentioned in the announcements we worked out a list of blockers we saw in adopting the GitLab CE, some of which had existing solutions in the GitLab Enterprise Edition. We submitted this feedback to GitLab, both via a master account ticket we kept with them as well as by being active in individual tickets. We also aligned our requirements with other open source communities around us (e.g. our friends at Gnome and VideoLAN) to take opportunities to communicate them with one voice. As a result some functionality of GitLab EE has been migrated to GitLab CE (or GitLab Core, which both build on, to be correct). A very important one for us just recently in 13.1 - Merge Request Reviews. We're really happy that GitLab takes feedback from the open source software community seriously and engages in productive dialog about it wrt/ the CE (a good relationship with upstream has always been #1 for KDE's tooling choices). Conversely, KDE has a long and proud history of lifting up the communities relying on the tools it adopts (we've contributed in significant ways to SVN, valgrind, CMake, gitolite, Redmine and many other tools we've been using over the years) and we're happy other users will benefit from the more powerful CE. --Eike, KDE e.V.
    - ragerino 6y ago
      That's awesome. Thank you!
    - sytse 6y ago
      Thanks KDE for the great collaboration. Your pragmatism and patience are greatly appreciate. Glad we could make this partnership work well.
      - sho_hn 6y ago
        Likewise, thanks to you and the team! :-) Looking forward to the future in the GitLab community.
rvz 6y ago
Great news for KDE and open source. Self-hosting with something like GitLab, Gitea, etc is still an option if you are dealing with an open-source project like GNOME, Xfce, etc. This allows you to control your data, source-code and the server if it goes down with the sys-admins to maintain it and you can still mirror your official repository from GitLab/Gitea to GitHub. It isn't a good idea to 'centralise everything' [0] on a server or VM instance that you don't own, which is why self-hosting is better for companies and open-source projects than on GitHub. [0] https://news.ycombinator.com/item?id=22867803 https://news.ycombinator.com/item?id=22867803
- slezyr 6y ago
  It's not about GitHub, it's interesting that they move from Phabricator(?) to GitLab.
- rH61W3epxeHMjg4 6y ago
  Many open source projects are self-hosting Gitlab: Gnome: https://gitlab.gnome.org/GNOME https://gitlab.gnome.org/GNOME Freedesktop : https://gitlab.freedesktop.org/explore/groups https://gitlab.freedesktop.org/explore/groups Arch Linux : https://gitlab.archlinux.org/archlinux https://gitlab.archlinux.org/archlinux
  - mixologic 6y ago
    Drupal: https://git.drupalcode.org https://git.drupalcode.org
  - mixologic 6y ago
    Debian: https://salsa.debian.org/public https://salsa.debian.org/public
  - zelphirkalt 6y ago
    Free a.k.a. libre, not open. Ot's even in the name this time …
- ssutch3 6y ago
  KDE is "self hosting" https://invent.kde.org/public/ https://invent.kde.org/public/
cptskippy 6y ago
Did I read that correctly, they were on Subversion before this?
- quantummkv 6y ago
  Only the translation communities, according to the article. But I wouldn't be surprised if more of the repositories were on subversion. There was no git in the 90's when KDE started
  - lbeltrame 6y ago
    Only the translation teams use SVN (and perhaps some very old websites, but I think most if not all of them have been moved to git). All the code lives on git, instead.
  - wheels 6y ago
    > There was no git in the 90's when KDE started There was no Subversion when KDE started. Like most projects of its era, KDE started with CVS, and moved to Subversion in 2005.
    - sho_hn 6y ago
      In fact, I recall we had to contribute code to SVN to make it scale to our existing monorepo size :-)
  - ognarb 6y ago
    There is still some websites on SVN but I started moving them to git. The only one missing are the one from unmaintained project that I should import in git and then archive.
- ahartmetz 6y ago
  It was Subversion until 2010 or so. After that, Git with... I think Reviewboard (and various other tools), then Phabricator, soon (and some parts already) GitLab.
- deleted 6y ago
thaumaturgy 6y ago
Jumping onto one of the most popular source control platforms is a really good move for KDE, but I'm a bit disappointed to read this. Phabricator is a really excellent piece of software, and seeing large projects like KDE running on it gave me hope that it would have a long life ahead still.
- slezyr 6y ago
  I can't blame them, GitLab's CI integration is great. Take a look at it: https://invent.kde.org/network/kaidan/-/pipelines/25364 https://invent.kde.org/network/kaidan/-/pipelines/25364 I've tried to find same in the Blender's phabricator and it doesn't look that they have CI support at all.
  - thaumaturgy 6y ago
    Yep. Phabricator kiiiinda has CI through Harbormaster, but it's not well documented and only sorta kinda works, and if I remember right, requires running arcanist commands locally. It's way far behind what other platforms are doing.
    - slezyr 6y ago
      Ah, it reminds me of another issue - AWS-type naming (harbormaster, maniphest, phriction, diffusion, differential) I simply can't what are those without clicking them.
      - thaumaturgy 6y ago
        The naming style wasn't great, but you get used to it, like anything else. The architecture itself was beautiful; rather than trying to build a single monolithic application, the developers built a federated suite of applications that all shared a common architecture. This made it possible for the developers to treat each Phabricator component as a separate project and also allowed Phabricator administrators to set up a la carte configurations according to the organization's specific needs.
nfoz 6y ago
What advantages do people like from Gitlab as opposed to just using git? I'm not too familiar with gitlab/github, so I'm sure it's a naive question, but I'm wondering what the main value-add that's missing from the basic tools is?
- Denvercoder9 6y ago
  CI, issue tracker, pull requests, etc.
- beisner 6y ago
  Git is a version control system, whereas Gitlab/Github are source-code hosting applications. You use git to interact with Gitlab/Github. Without going too in-depth, they allow teams to set up accounts on a central website, where team members can contribute to that central git repository. There are also other project-management features baked into the tool (code review, issue tracking, etc). Of course, this can all be done using a bare git server running on some publicly-available computer, but they offer nice UIs and very friendly onboarding so that makes them attractive for teams.
  - ebg13 6y ago
    > whereas Gitlab/Github are source-code hosting applications I would amend that to "source-code collaboration applications". The hosting is not the important part.
- thaumaturgy 6y ago
  Fair question, you shouldn't be getting downvoted for it imo. Larger projects need a way to collect bug reports, feature requests, maintain documentation, and set up milestones and release schedules, at a minimum. Ideally you want all of this integrated into your vcs, so that when a developer decides to push a commit related to a specific bug or feature request, that commit gets attached to that bug or feature request. When these are set up and run well, they are very powerful for mid-to-larger organizations.
  - fimbulvetr 6y ago
tapoxi 6y ago
Since there's other large open-source projects on GitLab too (namely GNOME) I think it would be pretty neat if there was some sort of ActivityPub-esque federation between GitLab instances, to foster a sense of community in an application that's more distributed than GitHub is. You miss out on a lot with so many teams living in their own bubble.
- q3k 6y ago
  You might be interested in ForgeFed [1]. [1] - https://forgefed.peers.community/ https://forgefed.peers.community/
- jfkebwjsbx 6y ago
  I genuinely ask: why is "a sense of community" important in a productivity tool? I have never cared about all the "social features" that work tools seem to always end up introducing...
  - beamatronic 6y ago
    Right? If I wanted to deal with people I wouldn't have become a computer programmer.
    - jfkebwjsbx 6y ago
      It is not about being social or not (I am a quite social individual), but about the context that I am wondering. When I am working, I am not trying to be social but to be professional.
  - tapoxi 6y ago
    Software is a collaborative effort, and the easier you make it to collaborate and share information with others, the better. Imagine @ing a GNOME dev in a different instance to comment on a bug report in KDE, or seeing an newsfeed update that your favorite framework is making a breaking change in the next release, or opening a PR/MR in another project without having to create _yet another_ account. You don't need to use any of those, but I think that the large community is partly what makes GitHub such a valuable tool.
nikisweeting 6y ago
Has anyone built a bridge that mirrors issues between Github & Gitlab? (the codebase can obv. just be synced via git itself) Would be awesome if you could pick your platform without losing all the devs who only use one platform or the other to discuss issues.
- abalaji 6y ago
  GitHub and GitLab have visual indications for the mirroring you mentioned, example: • https://github.com/PyCQA/flake8 https://github.com/PyCQA/flake8 • https://gitlab.com/pycqa/flake8 https://gitlab.com/pycqa/flake8 I'm not aware of any tools that sync issues between the platforms. But, I'm sure someone could build something to set that up using GitHub Actions / GitLab CI.
- DreamScatter 6y ago
  I just simply push my commits to both GitHub and GitLab, which is trivial to setup.
  - nikisweeting 6y ago
    > ... that mirrors issues between Github & Gitlab?
LockAndLol 6y ago
Hopefully with the coordinated move to gitlab and the now greater existence of Gitlab instances, there will be a push towards ForgeFed[0] which will allow cross-instance merge requests, forking, issue creation and more. I imagine it would make collaboration between different instances / groups easier e.g a KDE developer won't have to create an account on Debian's gitlab in order to fork a project or create an MR, but simply stay on the KDE instance, do all the work there and then submit a cross-instance MR. 0: https://forgefed.peers.community/ https://forgefed.peers.community/
rhabarba 6y ago
How fitting: One of the most over-engineered desktop environments moves from one obscure hosting facility for the most unnecessarily complicated version control system to another.
zmmmmm 6y ago
I think this is great but the "Why KDE moved to GitLab" section is downright weird - doesn't seem to provide any clear reason why and mostly talks about how hard it is. Why put that section in if then to not properly address it? It is almost counterproductive because it makes me really wonder now why when they can't actually state a clear advantage.
- deleted 6y ago
  [deleted]
- ogre_codes 6y ago
  I was kind of scratching my head here too. It didn't say what platform it was on previously, what limits/ benefits they were looking for that made GitLab appealing. Just "It was the next logical choice"... why did they name the article "Why the KDE community is #MovingToGitlab" when they barely breached the topic?
- bondia 6y ago
  KDE moved because Phabricator is practically abandoned and KDE can't take it over. Furthermore, all KDE development is based on git and Phabricator abstracts the versioning systems, making the naming of things weird. They require weird cli integration (arcanist) not to rely on git semantics. Most contributors expect gitlab/github kind of workflows on the other hand. It's really not great to make newcomers learn how to use arc (which is really not that good and barely used elsewhere) when they can learn proper git commands that will be useful for them in many aspects of their professional life, or just reuse the knowledge if they're already familiar. I understand whoever wrote the article didn't want to be complaining about Phabricator as much as talking about how good gitlab is.
  - epriest 6y ago
    Why do you believe Phabricator is practically abandoned?
  - evilelectron 6y ago
    Not as per their git commit history https://github.com/phacility/phabricator https://github.com/phacility/phabricator
x3haloed 6y ago
Great sales pitch. The part that’s missing is the most important part: why they chase GitLab instead of a competitor.
- SXX 6y ago
  What competitor? There are no other open source offering that suitable for KDE.
  - x3haloed 6y ago
    GitHub? Gitea?
    - SXX 6y ago
      GitHub is not open source. Gitea don't even have CI/CD.
jdlyga 6y ago
There's certain projects that you could leave and come back to after a few years and they're largely the same. But it's amazing how much more reliable, efficient, and user friendly KDE Plasma is even in a few short years.
krob 6y ago
I think it's a mistake for them to leave phabricator. This product is quite easy to get ci/cd going on. There are apis to submit back to tickets. it's highly customizable. Also the damn system never breaks; even when you think it broke. Git pull and run the migration tool. boom. Its a PHP system after all. Probably one of the most well written and methodical codebases out there. Also the community fixes bugs regularly, especially if they're simple and easy to replicate.
- ollyculverhouse 6y ago
  All of which you get with Gitlab plus a first class CI/CD system out of the box and a more popular (read familiar) interface which reduces the friction for new developers to get started with KDE.
pepemon 6y ago
How does KDE go around the absence of merge approvals in CE? I think that this is the vital functionality for large and complex projects like KDE.
- noahadavis 6y ago
  Only KDE devs can merge MRs. We review, say that the patch looks good in a comment and then merge.
entha_saava 6y ago
My small problem with gitlab is that the website is slow and heavy JS, especially having to use it on mobile (expectable that you can respond in issue trackers from mobile). GitHub is comparatively faster and less cluttered UI. I know this is not a significant problem. But I mentioned it since Gitlab people are sometimes commenting here. :)
- joshlambert 6y ago
  Thanks for the feedback entha_saava. GitLab.com is indeed slower than GitHub.com today, and we need to provide a better experience for our users. Improving frontend performance is a key focus area for us, and while we started this specific initiative recently, we have started prefetching data while our Vue app is loading (https://gitlab.com/gitlab-org/gitlab/-/issues/220511 https://gitlab.com/gitlab-org/gitlab/-/issues/220511) and will be splitting out page specific assets out of the main bundle (https://gitlab.com/groups/gitlab-org/-/epics/3694 https://gitlab.com/groups/gitlab-org/-/epics/3694). We have quite a few other initiatives in flight, and will continue to provide updates on progress which you can see here: https://gitlab.com/groups/gitlab-org/-/epics/3273#note_370914819 https://gitlab.com/groups/gitlab-org/-/epics/3273#note_37091...

419 points by caution 6y ago

Jonnax 6y ago

It's cool that KDE are using the Community Edition if Gitlab

jsiepkes 6y ago
So how do they deal with (what seems to me) basic functionality that the Gitlab community edition is missing? Like for example linking issues as related?
- sho_hn 6y ago
  We told our friends at GitLab from the start that we would be running the Community Edition, as our policies and principles require. During the eval phase mentioned in the announcements we worked out a list of blockers we saw in adopting the GitLab CE, some of which had existing solutions in the GitLab Enterprise Edition. We submitted this feedback to GitLab, both via a master account ticket we kept with them as well as by being active in individual tickets. We also aligned our requirements with other open source communities around us (e.g. our friends at Gnome and VideoLAN) to take opportunities to communicate them with one voice. As a result some functionality of GitLab EE has been migrated to GitLab CE (or GitLab Core, which both build on, to be correct). A very important one for us just recently in 13.1 - Merge Request Reviews. We're really happy that GitLab takes feedback from the open source software community seriously and engages in productive dialog about it wrt/ the CE (a good relationship with upstream has always been #1 for KDE's tooling choices). Conversely, KDE has a long and proud history of lifting up the communities relying on the tools it adopts (we've contributed in significant ways to SVN, valgrind, CMake, gitolite, Redmine and many other tools we've been using over the years) and we're happy other users will benefit from the more powerful CE. --Eike, KDE e.V.
  - ragerino 6y ago
    That's awesome. Thank you!
  - sytse 6y ago
    Thanks KDE for the great collaboration. Your pragmatism and patience are greatly appreciate. Glad we could make this partnership work well.
    - sho_hn 6y ago
      Likewise, thanks to you and the team! :-) Looking forward to the future in the GitLab community.

rvz 6y ago

Great news for KDE and open source. Self-hosting with something like GitLab, Gitea, etc is still an option if you are dealing with an open-source project like GNOME, Xfce, etc. This allows you to control your data, source-code and the server if it goes down with the sys-admins to maintain it and you can still mirror your official repository from GitLab/Gitea to GitHub. It isn't a good idea to 'centralise everything' [0] on a server or VM instance that you don't own, which is why self-hosting is better for companies and open-source projects than on GitHub. [0] https://news.ycombinator.com/item?id=22867803 https://news.ycombinator.com/item?id=22867803

slezyr 6y ago
It's not about GitHub, it's interesting that they move from Phabricator(?) to GitLab.
rH61W3epxeHMjg4 6y ago
Many open source projects are self-hosting Gitlab: Gnome: https://gitlab.gnome.org/GNOME https://gitlab.gnome.org/GNOME Freedesktop : https://gitlab.freedesktop.org/explore/groups https://gitlab.freedesktop.org/explore/groups Arch Linux : https://gitlab.archlinux.org/archlinux https://gitlab.archlinux.org/archlinux
- mixologic 6y ago
  Drupal: https://git.drupalcode.org https://git.drupalcode.org
- mixologic 6y ago
  Debian: https://salsa.debian.org/public https://salsa.debian.org/public
- zelphirkalt 6y ago
  Free a.k.a. libre, not open. Ot's even in the name this time …
ssutch3 6y ago
KDE is "self hosting" https://invent.kde.org/public/ https://invent.kde.org/public/

cptskippy 6y ago

Did I read that correctly, they were on Subversion before this?

quantummkv 6y ago
Only the translation communities, according to the article. But I wouldn't be surprised if more of the repositories were on subversion. There was no git in the 90's when KDE started
- lbeltrame 6y ago
  Only the translation teams use SVN (and perhaps some very old websites, but I think most if not all of them have been moved to git). All the code lives on git, instead.
- wheels 6y ago
  > There was no git in the 90's when KDE started There was no Subversion when KDE started. Like most projects of its era, KDE started with CVS, and moved to Subversion in 2005.
  - sho_hn 6y ago
    In fact, I recall we had to contribute code to SVN to make it scale to our existing monorepo size :-)
- ognarb 6y ago
  There is still some websites on SVN but I started moving them to git. The only one missing are the one from unmaintained project that I should import in git and then archive.
ahartmetz 6y ago
It was Subversion until 2010 or so. After that, Git with... I think Reviewboard (and various other tools), then Phabricator, soon (and some parts already) GitLab.
deleted 6y ago

thaumaturgy 6y ago

Jumping onto one of the most popular source control platforms is a really good move for KDE, but I'm a bit disappointed to read this. Phabricator is a really excellent piece of software, and seeing large projects like KDE running on it gave me hope that it would have a long life ahead still.

slezyr 6y ago
I can't blame them, GitLab's CI integration is great. Take a look at it: https://invent.kde.org/network/kaidan/-/pipelines/25364 https://invent.kde.org/network/kaidan/-/pipelines/25364 I've tried to find same in the Blender's phabricator and it doesn't look that they have CI support at all.
- thaumaturgy 6y ago
  Yep. Phabricator kiiiinda has CI through Harbormaster, but it's not well documented and only sorta kinda works, and if I remember right, requires running arcanist commands locally. It's way far behind what other platforms are doing.
  - slezyr 6y ago
    Ah, it reminds me of another issue - AWS-type naming (harbormaster, maniphest, phriction, diffusion, differential) I simply can't what are those without clicking them.
    - thaumaturgy 6y ago
      The naming style wasn't great, but you get used to it, like anything else. The architecture itself was beautiful; rather than trying to build a single monolithic application, the developers built a federated suite of applications that all shared a common architecture. This made it possible for the developers to treat each Phabricator component as a separate project and also allowed Phabricator administrators to set up a la carte configurations according to the organization's specific needs.

nfoz 6y ago

What advantages do people like from Gitlab as opposed to just using git? I'm not too familiar with gitlab/github, so I'm sure it's a naive question, but I'm wondering what the main value-add that's missing from the basic tools is?

Denvercoder9 6y ago
CI, issue tracker, pull requests, etc.
beisner 6y ago
Git is a version control system, whereas Gitlab/Github are source-code hosting applications. You use git to interact with Gitlab/Github. Without going too in-depth, they allow teams to set up accounts on a central website, where team members can contribute to that central git repository. There are also other project-management features baked into the tool (code review, issue tracking, etc). Of course, this can all be done using a bare git server running on some publicly-available computer, but they offer nice UIs and very friendly onboarding so that makes them attractive for teams.
- ebg13 6y ago
  > whereas Gitlab/Github are source-code hosting applications I would amend that to "source-code collaboration applications". The hosting is not the important part.
thaumaturgy 6y ago
Fair question, you shouldn't be getting downvoted for it imo. Larger projects need a way to collect bug reports, feature requests, maintain documentation, and set up milestones and release schedules, at a minimum. Ideally you want all of this integrated into your vcs, so that when a developer decides to push a commit related to a specific bug or feature request, that commit gets attached to that bug or feature request. When these are set up and run well, they are very powerful for mid-to-larger organizations.
- fimbulvetr 6y ago

tapoxi 6y ago

Since there's other large open-source projects on GitLab too (namely GNOME) I think it would be pretty neat if there was some sort of ActivityPub-esque federation between GitLab instances, to foster a sense of community in an application that's more distributed than GitHub is. You miss out on a lot with so many teams living in their own bubble.

q3k 6y ago
You might be interested in ForgeFed [1]. [1] - https://forgefed.peers.community/ https://forgefed.peers.community/
jfkebwjsbx 6y ago
I genuinely ask: why is "a sense of community" important in a productivity tool? I have never cared about all the "social features" that work tools seem to always end up introducing...
- beamatronic 6y ago
  Right? If I wanted to deal with people I wouldn't have become a computer programmer.
  - jfkebwjsbx 6y ago
    It is not about being social or not (I am a quite social individual), but about the context that I am wondering. When I am working, I am not trying to be social but to be professional.
- tapoxi 6y ago
  Software is a collaborative effort, and the easier you make it to collaborate and share information with others, the better. Imagine @ing a GNOME dev in a different instance to comment on a bug report in KDE, or seeing an newsfeed update that your favorite framework is making a breaking change in the next release, or opening a PR/MR in another project without having to create _yet another_ account. You don't need to use any of those, but I think that the large community is partly what makes GitHub such a valuable tool.

nikisweeting 6y ago

Has anyone built a bridge that mirrors issues between Github & Gitlab? (the codebase can obv. just be synced via git itself) Would be awesome if you could pick your platform without losing all the devs who only use one platform or the other to discuss issues.

abalaji 6y ago
GitHub and GitLab have visual indications for the mirroring you mentioned, example: • https://github.com/PyCQA/flake8 https://github.com/PyCQA/flake8 • https://gitlab.com/pycqa/flake8 https://gitlab.com/pycqa/flake8 I'm not aware of any tools that sync issues between the platforms. But, I'm sure someone could build something to set that up using GitHub Actions / GitLab CI.
DreamScatter 6y ago
I just simply push my commits to both GitHub and GitLab, which is trivial to setup.
- nikisweeting 6y ago
  > ... that mirrors issues between Github & Gitlab?

LockAndLol 6y ago

Hopefully with the coordinated move to gitlab and the now greater existence of Gitlab instances, there will be a push towards ForgeFed[0] which will allow cross-instance merge requests, forking, issue creation and more. I imagine it would make collaboration between different instances / groups easier e.g a KDE developer won't have to create an account on Debian's gitlab in order to fork a project or create an MR, but simply stay on the KDE instance, do all the work there and then submit a cross-instance MR. 0: https://forgefed.peers.community/ https://forgefed.peers.community/

rhabarba 6y ago

How fitting: One of the most over-engineered desktop environments moves from one obscure hosting facility for the most unnecessarily complicated version control system to another.

zmmmmm 6y ago

I think this is great but the "Why KDE moved to GitLab" section is downright weird - doesn't seem to provide any clear reason why and mostly talks about how hard it is. Why put that section in if then to not properly address it? It is almost counterproductive because it makes me really wonder now why when they can't actually state a clear advantage.

deleted 6y ago
[deleted]
ogre_codes 6y ago
I was kind of scratching my head here too. It didn't say what platform it was on previously, what limits/ benefits they were looking for that made GitLab appealing. Just "It was the next logical choice"... why did they name the article "Why the KDE community is #MovingToGitlab" when they barely breached the topic?
bondia 6y ago
KDE moved because Phabricator is practically abandoned and KDE can't take it over. Furthermore, all KDE development is based on git and Phabricator abstracts the versioning systems, making the naming of things weird. They require weird cli integration (arcanist) not to rely on git semantics. Most contributors expect gitlab/github kind of workflows on the other hand. It's really not great to make newcomers learn how to use arc (which is really not that good and barely used elsewhere) when they can learn proper git commands that will be useful for them in many aspects of their professional life, or just reuse the knowledge if they're already familiar. I understand whoever wrote the article didn't want to be complaining about Phabricator as much as talking about how good gitlab is.
- epriest 6y ago
  Why do you believe Phabricator is practically abandoned?
- evilelectron 6y ago
  Not as per their git commit history https://github.com/phacility/phabricator https://github.com/phacility/phabricator

x3haloed 6y ago

Great sales pitch. The part that’s missing is the most important part: why they chase GitLab instead of a competitor.

SXX 6y ago
What competitor? There are no other open source offering that suitable for KDE.
- x3haloed 6y ago
  GitHub? Gitea?
  - SXX 6y ago
    GitHub is not open source. Gitea don't even have CI/CD.

jdlyga 6y ago

There's certain projects that you could leave and come back to after a few years and they're largely the same. But it's amazing how much more reliable, efficient, and user friendly KDE Plasma is even in a few short years.

krob 6y ago

I think it's a mistake for them to leave phabricator. This product is quite easy to get ci/cd going on. There are apis to submit back to tickets. it's highly customizable. Also the damn system never breaks; even when you think it broke. Git pull and run the migration tool. boom. Its a PHP system after all. Probably one of the most well written and methodical codebases out there. Also the community fixes bugs regularly, especially if they're simple and easy to replicate.

ollyculverhouse 6y ago
All of which you get with Gitlab plus a first class CI/CD system out of the box and a more popular (read familiar) interface which reduces the friction for new developers to get started with KDE.

pepemon 6y ago

How does KDE go around the absence of merge approvals in CE? I think that this is the vital functionality for large and complex projects like KDE.

noahadavis 6y ago
Only KDE devs can merge MRs. We review, say that the patch looks good in a comment and then merge.

entha_saava 6y ago

My small problem with gitlab is that the website is slow and heavy JS, especially having to use it on mobile (expectable that you can respond in issue trackers from mobile). GitHub is comparatively faster and less cluttered UI. I know this is not a significant problem. But I mentioned it since Gitlab people are sometimes commenting here. :)

joshlambert 6y ago
Thanks for the feedback entha_saava. GitLab.com is indeed slower than GitHub.com today, and we need to provide a better experience for our users. Improving frontend performance is a key focus area for us, and while we started this specific initiative recently, we have started prefetching data while our Vue app is loading (https://gitlab.com/gitlab-org/gitlab/-/issues/220511 https://gitlab.com/gitlab-org/gitlab/-/issues/220511) and will be splitting out page specific assets out of the main bundle (https://gitlab.com/groups/gitlab-org/-/epics/3694 https://gitlab.com/groups/gitlab-org/-/epics/3694). We have quite a few other initiatives in flight, and will continue to provide updates on progress which you can see here: https://gitlab.com/groups/gitlab-org/-/epics/3273#note_370914819 https://gitlab.com/groups/gitlab-org/-/epics/3273#note_37091...