Koko in KDEReview

[Harald Sitter]

On 04.05.21 17:53, Carl Schwan wrote:
> Le mardi, mai 4, 2021 4:53 PM, Adriaan de Groot <groot at kde.org> a écrit :
> 
>> On Tuesday, 4 May 2021 15:50:27 CEST Halla Rempt wrote:
>>
>>> On Tuesday, 4 May 2021 15:28:30 CEST Nate Graham wrote:
>>>
>>>> I don't see anyone really trying to argue otherwise.
>>>
>>> I have certainly made that argument many times. Since only developers can
>>> add tags, it will be impossible for ordinary users to provide enough
>>> information to classify the bug. Tagging systems suck big-time. Looking it
>>> GIMP's gitlab issues shows that not even the OS is reliably tagged!
>>
>> What Halla said. Every time we have this conversation, Krita is the special
>> case, because it is a special case -- many many users, diverse platforms,
>> non-technical bug-reports. We must not discount Krita's experiences and needs
>> -- conversely not ignore the needs of some obscure edge-case tool that is only
>> going to get FreeBSD sysadmins to file bug reports (which might be fine in
>> GitLab issues, because there's only ever 3 users).
> 
> If Bugzilla was working so well for Krita, I'm wondering why they are redirecting
> their users to write their bug reports first in an external tool (krita-artists.org)
> instead of Bugzilla.

Passive aggression really doesn't move the debate forward :(

> Some documentation website aren't using docs.kde.org but their own tooling
> (e.g. docs.krita.org, docs.plasma-mobile.org, ...), should we also force them
> to use docs.kde.org? Should we force every project to use forum.kde.org?

... neither do straw men.

> Any migration has to be able to handle huge numbers of issues, and also
>> provide maintainers tools to manage them, and to handle the diversity of issue
>> meta-data that bugzilla handles.
>>
>> To move this conversation forward, we'd need a concrete example of "these are
>> the tools used to manage issue lifecycle, similar to how bugs lifecycle in
>> bugzilla works". I know Harald has built tools and views and things to help
>> out there, but we do need a .. well, a concrete proposal for how things would
>> work.
> 
> Currently, the extra tooling we maintain for closing bugs and adding comments in Bugzilla
> when an MR is opened is currently natively supported by GitLab. For bug triagging,
> there is also a very helpful tool made by GitLab: https://gitlab.com/gitlab-org/gitlab-triage
> 
> This tool allows for example to add special labels when an issue/MR, older than a
> few days, didn't get any comments yet or adding automatically OS labels when
> Windows/Arch/FreeBSD is mentioned in the issue.

Yep. I think to drive the point home: We have solved a great many things
with tooling, we may be able to get rid of some, we may need to add some
more, but we first need to know what the great many things (not just
tooling I guess) are that we do and rely on. Only then can we actually
a) go "yes, let's move" b) "here's the migration plan". Gitlab
insufficiencies may well be solved by some extra magic put on top.

So, I suggest that someone who cares to migrate sits down with the major
stake holders and figures out what we have come to rely on in bugz that
isn't available in gitlab (OS, versions, version supportedness, personal
tags, moving bugs between projects, global search etc.), and also what
gitlab does better or might improve. Write all the stuff down on a wiki
page. Then we can think about how to deal with the various problems. And
maybe in the end the answer is not everyone can have the same BTS.
Martin has raised a really good point there. But we really, really,
really do not want a 50/50 split and everyone picks the system that
takes their fancy and then we need twice the
tooling/solutions/clientsoftware AND on top of everything figure out how
to bounce bugs between two systems. It'd not be sustainable.

> Also, it's important to note that different teams have different needs and finding
> a tool that fits everyone will be very difficult. For example in NeoChat, I have
> special needs like asking the bug reporter to add some information about the
> matrix instance used, the libQuotient version used, ... and for that, I need a
> special bug reports template. Something that Bugzilla doesn't provide and without
> it, the bugs report are in many cases worthless.

Side note: this isn't a special need TBH ;)
Pretty much everyone has that need. So much so that I kind of have a
general game plan that there ought to be a kbugreport utility which is
able to gobble up all the very specific data $product needs through
scripts or something and either attaches the data to an existing report
or files a new one. Cause a filing template also only gets you so far  +
for the causal user it's still a fairly meh experience.

HS