Hacker News Reader

Comment by przmk | Hacker News Reader

They are currently on Phabricator if I'm not mistaken.

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.

View on HN

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.

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.

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

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

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

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.

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.

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.

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.

Are there more details on why they specifically have chosen to move? Maybe there were some discussions in some public mailing lists?

I found this exploration ticket from a year ago:

https://gitlab.com/gitlab-org/gitlab-foss/issues/53206

Nothing on the mailing lists as far as I can tell.

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), 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.

> 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

> 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

Reply on news.ycombinator.com