[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-community
Subject:    Re: Invent/gitlab, issues and bugzilla
From:       Eike Hein <hein () kde ! org>
Date:       2019-07-05 1:03:41
Message-ID: 6DE0C9FF-1FD5-4424-A389-4723F539F3AE () kde ! org
[Download RAW message or body]

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


[Attachment #3 (text/html)]

I think this discussion has sort of strayed, if understandably so=2E Maybe =
this helps:<br><br>- A lot of projects currently use Phabricator tasks and =
rely on them heavily=2E<br>- The GitLab equivalent are Issues=2E<br>- We're=
 trying to replace Phabricator with GitLab=2E<br>- If Issues are disabled, =
we can't import the Phab tasks=2E<br><br>This is lossy and unacceptable=2E =
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=2E<br><br>As for whether Issues can be used for bug reports, tha=
t's a seperate policy dimension from the above=2E 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=2E<br><br>The relevant part of the KDE Manifesto isn't anything a=
bout hosting infrastructure, it's the "Common Ownership" one: Without a uni=
fied bug tracker, it's not possible to conveniently reassign bugs between p=
roducts or do queries against the entire database=2E We do this and rely on=
 this all the time, and our software and community are better and stronger =
for it=2E Projects that would trade this benefit aren't well-integrated in =
the sense of understanding what becoming part of KDE truly gets them, and t=
hen we should do a better job telling them, because it's pretty awesome=2E<=
br><br>If we migrate bug tracking at a later time, it should be in one swoo=
p=2E I see this as a separate project from Phab-to-GitLab at this time=2E<b=
r><br>With my maintainer hat on personally I also agree with Boud that a li=
ne between dev task tracking and bug reports is healthy for larger projects=
=2E They seem to be smart enough to figure that out on their own, though=2E=
 <br><br>Such a separation doesn't necessarily mean needing two web apps=2E=
 It does however mean figuring out our needs for both types of activity, ou=
r needs for how they need to be seperated, and checking if the One True App=
 meets all of those needs=2E And if it doesn't, looking into talking to its=
 developers to improve it=2E On that note I'll add that one of the major re=
asons we are migrating to GitLab is that we can actually talk to them and h=
ave them respond: This is exciting and fits the pattern of KDE making succe=
ssful tooling choices based on strong upstream relations=2E Let's not forge=
t that and get burned out over internal haggling=2E<br><br>This requires a =
process, and a much better one than shouting at each other in a convuluted =
mailing list thread=2E :)<br><br><br>Cheers,<br>Eike<br><br>

[prev in list] [next in list] [prev in thread] [next in thread]