Koko in KDEReview

[Carl Schwan]

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.

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

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.

I really don't think forcing every KDE project to use Bugzilla is a good idea.
As long as it uses KDE infra it should be fine (compliance with our manifesto).
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?

> That it's possible to manage a gazillion issues in GitLab (maybe EE
> features, though) can be seen by looking at https://gitlab.com/gitlab-org/
> gitlab/-/issues GitLab issues in GitLab: there's 37 thousand of them, but
> there's also 78 pages of labels at https://gitlab.com/gitlab-org/gitlab/-/
> labels to pick from. I suspect there's a non-0 amount of FTE's doing bug-
> labeling -- can we afford that?
>
> [ade]