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

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


Reply via email to