From kde-community Fri Jul 05 01:03:41 2019 From: Eike Hein Date: Fri, 05 Jul 2019 01:03:41 +0000 To: kde-community Subject: Re: Invent/gitlab, issues and bugzilla Message-Id: <6DE0C9FF-1FD5-4424-A389-4723F539F3AE () kde ! org> X-MARC-Message: https://marc.info/?l=kde-community&m=156228866406438 MIME-Version: 1 Content-Type: multipart/mixed; boundary="------Q97ZU6RMSVXALN6UF5G6G03F0YT6MO" ------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--