Invent/gitlab, issues and bugzilla

[Eike Hein]

I think this discussion has sort of strayed, if understandably so. Maybe this helps:

- A lot of projects currently use Phabricator tasks and rely on them heavily.
- The GitLab equivalent are Issues.
- We're trying to replace Phabricator with GitLab.
- If Issues are disabled, we can't import the Phab tasks.

This is lossy and unacceptable. I expect to find my Phab tasks in GitLab when my projects are migrated, and getting those migration ducks in a row is, in my mind, primarily why they aren't yet.

As for whether Issues can be used for bug reports, that's a seperate policy dimension from the above. We didn't write rules on this for Phabricator, and maybe we don't need to for GitLab, either, but at the same time it's very clear that KDE projects need to have a presence on Bugzilla.

The relevant part of the KDE Manifesto isn't anything about hosting infrastructure, it's the "Common Ownership" one: Without a unified bug tracker, it's not possible to conveniently reassign bugs between products or do queries against the entire database. We do this and rely on this all the time, and our software and community are better and stronger for it. Projects that would trade this benefit aren't well-integrated in the sense of understanding what becoming part of KDE truly gets them, and then we should do a better job telling them, because it's pretty awesome.

If we migrate bug tracking at a later time, it should be in one swoop. I see this as a separate project from Phab-to-GitLab at this time.

With my maintainer hat on personally I also agree with Boud that a line between dev task tracking and bug reports is healthy for larger projects. They seem to be smart enough to figure that out on their own, though. 

Such a separation doesn't necessarily mean needing two web apps. It does however mean figuring out our needs for both types of activity, our needs for how they need to be seperated, and checking if the One True App meets all of those needs. And if it doesn't, looking into talking to its developers to improve it. On that note I'll add that one of the major reasons we are migrating to GitLab is that we can actually talk to them and have them respond: This is exciting and fits the pattern of KDE making successful tooling choices based on strong upstream relations. Let's not forget that and get burned out over internal haggling.

This requires a process, and a much better one than shouting at each other in a convuluted mailing list thread. :)


Cheers,
Eike

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-community/attachments/20190705/c580ead1/attachment.htm>