------Q97ZU6RMSVXALN6UF5G6G03F0YT6MO
Content-Type: text/plain;
charset=utf-8
Content-Transfer-Encoding: quoted-printable
I think this discussion has sort of strayed, if understandably so=2E Maybe =
this helps:
- A lot of projects currently use Phabricator tasks and rely on them heavi=
ly=2E
- The GitLab equivalent are Issues=2E
- We're trying to replace Phabricator with GitLab=2E
- If Issues are disabled, we can't import the Phab tasks=2E
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
As for whether Issues can be used for bug reports, that's a seperate polic=
y 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
The relevant part of the KDE Manifesto isn't anything about hosting infras=
tructure, it's the "Common Ownership" one: Without a unified bug tracker, i=
t's not possible to conveniently reassign bugs between products or do queri=
es 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 unders=
tanding what becoming part of KDE truly gets them, and then we should do a =
better job telling them, because it's pretty awesome=2E
If we migrate bug tracking at a later time, it should be in one swoop=2E I=
see this as a separate project from Phab-to-GitLab at this time=2E
With my maintainer hat on personally I also agree with Boud that a line be=
tween dev task tracking and bug reports is healthy for larger projects=2E T=
hey seem to be smart enough to figure that out on their own, though=2E=20
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, our needs =
for how they need to be seperated, and checking if the One True App meets a=
ll of those needs=2E And if it doesn't, looking into talking to its develop=
ers to improve it=2E 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 to=
oling choices based on strong upstream relations=2E Let's not forget that a=
nd get burned out over internal haggling=2E
This requires a process, and a much better one than shouting at each other=
in a convuluted mailing list thread=2E :)
Cheers,
Eike
------Q97ZU6RMSVXALN6UF5G6G03F0YT6MO
Content-Type: text/html;
charset=utf-8
Content-Transfer-Encoding: quoted-printable
I think this discussion has sort of strayed, if understandably so=2E Maybe =
this helps:
- A lot of projects currently use Phabricator tasks and =
rely on them heavily=2E
- The GitLab equivalent are Issues=2E
- We're=
trying to replace Phabricator with GitLab=2E
- If Issues are disabled, =
we can't import the Phab tasks=2E
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
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
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>
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
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=
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
This requires a =
process, and a much better one than shouting at each other in a convuluted =
mailing list thread=2E :)
Cheers,
Eike
------Q97ZU6RMSVXALN6UF5G6G03F0YT6MO--