
The KDE community is moving to GitLab - caution
https://about.gitlab.com/blog/2020/06/29/welcome-kde/
======
nfoz
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?

~~~
thaumaturgy
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
I would like to second this and point out that while someone can self host and
set all of this stuff up, at some points there are economies of scale for
using a provider to do this because the provider's raison d'etre is to create
these interfaces that make it easy for everyone to interact with git. The
developers on KDE, etc. probably don't want to spend their time working on the
UI for their bug/issue/feature/commit request tool when they could be working
on KDE things.

Finally, there's the fact that many more users will be familiar with GitLab
(or GitHub, BitBucket, and so on) than they would with each and every
opensource project's flavor of bug/issue/feature/commit tracker. For instance,
I know exactly how to find the "releases" section on github quickly - if KDE
wrote their own bug/issue/feature/commit tracker, I'd have to find the
"releases" area and remember where it is every time since I don't use that UI
as often as I use github.

~~~
eyegor
Actually, gitlab is open source and the majority of the features aren't pay
walled off. You can self host ~70% of the gitlab features on your own
hardware, without paying a dime. Or you can self host and pay a subscription
to enable all the enterprise features. At work, we use this for code which is
too sensitive to host outside of our infrastructure. Closed source development
needs management too.

------
rvz
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)

~~~
rH61W3epxeHMjg4
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
Debian: [https://salsa.debian.org/public](https://salsa.debian.org/public)

------
thaumaturgy
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
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
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
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
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.

~~~
evilelectron
Absolutely, diff (Differential) based patch review is a great workflow for
adding changes

------
tapoxi
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.

~~~
jfkebwjsbx
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...

~~~
tapoxi
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.

~~~
indigochill
> Imagine @ing a GNOME dev in a different instance to comment on a bug report
> in KDE

How do you see this being different from providing that dev with a hyperlink
to the bug report? In either case, the developer is made aware of the issue,
no?

> or seeing an newsfeed update that your favorite framework is making a
> breaking change in the next release

I don't actually know if changelists have RSS feeds, but supposing they did,
couldn't you subscribe your reader to those feeds to achieve this result?

> or opening a PR/MR in another project without having to create _yet another_
> account.

Yeah, you got me here. Though I'm leaning towards "build a physical key that
automates account creation everywhere" so you still have a zillion accounts
under the hood, but that's mostly transparent to the user. Sort of like
Facebook/Google SSO, but instead of storing data in one data-hungry corp's DB,
you're generating essentially random data in one place (your physical key) and
distributing it across zillions of little DBs, thus reducing the incentive for
hackers to try to obtain any of them.

~~~
R0b0t1
It's different from a hyperlink in that you don't need to potentially log into
a different project's infrastructure to share the information.

------
LockAndLol
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/)

------
zmmmmm
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.

~~~
bondia
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.

~~~
0xfaded
Did facebook stop using it internally? I'm personally in the phabricator camp,
but if it lost the backing of facebook I'd be seeing the writing on the wall.

~~~
epriest
Facebook has not provided any contributions or material support to the open
source version of Phabricator since around 2012.

------
jdlyga
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.

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

~~~
jsiepkes
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
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.

~~~
sytse
Thanks KDE for the great collaboration. Your pragmatism and patience are
greatly appreciate. Glad we could make this partnership work well.

~~~
sho_hn
Likewise, thanks to you and the team! :-) Looking forward to the future in the
GitLab community.

------
nikisweeting
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.

~~~
DreamScatter
I just simply push my commits to both GitHub and GitLab, which is trivial to
setup.

~~~
nikisweeting
> ... that mirrors _issues_ between Github & Gitlab?

------
krob
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
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
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
Only KDE devs can merge MRs. We review, say that the patch looks good in a
comment and then merge.

------
entha_saava
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
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_37091...](https://gitlab.com/groups/gitlab-
org/-/epics/3273#note_370914819)

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

~~~
quantummkv
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

~~~
wheels
> _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
In fact, I recall we had to contribute code to SVN to make it scale to our
existing monorepo size :-)

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

~~~
SXX
What competitor? There are no other open source offering that suitable for
KDE.

~~~
x3haloed
GitHub? Gitea?

~~~
SXX
GitHub is not open source.

Gitea don't even have CI/CD.

------
rhabarba
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.

