Web lists-archives.com

Re: Gitlab Evaluation & Migration

On Monday, 25 February 2019 09:12:47 CET Eike Hein wrote:
> On 2/25/19 4:31 AM, Martin Flöser wrote:
> > Changing the tooling will not solve any of the contribution problems.
> I'm aware of several projects who would like to incubate with KDE.org
> (e.g. Kaidan and Spectral, both new-breed Kirigami apps with new
> contributor ecosystems) but are waiting for the outcome of this
> decision, because they believe being part of KDE wouldn't be worth the
> cost of losing access to contributors that Phabricator imposes to them.
> It's difficult to get hard data on this, of course. From Gnome I've been
> told their contributon numbers from new contributors have seen a massive
> uptick since adopting GitLab, however their infra pre-GitLab was (to me)
> worse than Phabricator.
> It's unclear to me what exactly would happen for us. However, it seems
> clear to me that the world outside of the existing cadre of KDE
> contribtors has a consensus on this: When the news about the GitLab eval
> leaked to Reddit and other venues, "finally I'll be able to submit my
> patch" was a recurring theme.
> One thing that strikes me is that KDE upstream relations have usually
> been a defining trait of our tooling decisions. We've adopted things
> like gitolite, CMake and even Qt based on having an upstream to talk to.
> This is currently not the case with Phabricator, but it is the case with
> GitLab. I'm hesistant of saying it's awesome just yet (there's some
> features in the GitLab Enterprise Edition we would like GitLab to move
> to the Community Edition for us, and it's not been decided there yet),
> but they've done regular calls with us, opened a master ticket to track
> our account with them, and have multiple times expressed an interest in
> attending KDE's upcoming Onboarding sprint. This is very nice.
> It's also worth noting that we're the only big FOSS player using
> Phabricator at the moment. To contribute to KDE, people have to learn
> Phabricator. If they've already contributed to freedesktop, Gnome, or
> hundreds of other projects, they've already learned GitLab.
> My personal take is this: I'm used to Phabricator and fine with it. It
> doesn't impede my work. But I think it would be a mistake to make this
> decision based on what I'm fine with, because I'm equally able to adjust
> to GitLab and be fine with that. I'd rather make this decision based on
> what people who aren't KDE contributors yet find attractive, and that
> seems overwhelmingly in GitLab's favor from everything I've read and
> heard. New contributors showing up would affect me a lot more than
> having to adjust to typing a different command does.
> I also have reason to believe this delta between "I'm fine with it" and
> "Others want X" is only going to increase based on the relative
> development speeds of Phabricator and GitLab. The latter seems more
> likely to keep up with the state of the art currently. I'd like KDE to
> be on board with the state of the art.


+1 on everything Eike said. I think adopting GitLab will be a huge benefit for 

Some two-digit million amount of projects hosted on GitLab+GitHub+BitBucket 
(systems which all share the same "workflow" principles) cannot be wrong. At 
least there are /tons/ of developers out there which are familiar with them by 
heart, which makes it super easy for them to contribute to KDE, in theory.

Even after having worked a couple of years with Phabricator's review system it 
stills feels alien to me, mostly b/c it does not integrate that well with Git. 
I always get slight shivers when having to work with it. I'm contributing to 
several other projects on either GitLab, GitHub, BitBucket, and the whole 
experience is simply better. I think there's no doubt about that.

The move to yet another system is ambitious but let's rather do it sooner than 
later. Looking forward to GitLab adoption across the board!

Thanks for the effort, guys!


> Cheers,
> Eike

Kevin Funk | kfunk@xxxxxxx | http://kfunk.org

Attachment: signature.asc
Description: This is a digitally signed message part.