7 ms·

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

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

by przmk 7y ago

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.