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

List:       kde-core-devel
Subject:    Re: Koko in KDEReview
From:       Carl Schwan <carl () carlschwan ! eu>
Date:       2021-05-04 15:53:47
Message-ID: T82a_ycpZBCKbbbXzFhdBtunpe4JE8B9-Z2CKb-q6FxKIkf_DZKSTw7Zu-birfJ6xZWE8WH9Lm1780waZZnLjzrQkz5E23UQHFmFKW-VCN8= () carlschwan ! eu
[Download RAW message or body]

Le mardi, mai 4, 2021 4:53 PM, Adriaan de Groot <groot@kde.org> a =C3=A9cri=
t=C2=A0:

> 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 c=
an
> > 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 speci=
al
> case, because it is a special case -- many many users, diverse platforms,
> non-technical bug-reports. We must not discount Krita's experiences and n=
eeds
> -- 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 i=
n
> GitLab issues, because there's only ever 3 users).

If Bugzilla was working so well for Krita, I'm wondering why they are redir=
ecting
their users to write their bug reports first in an external tool (krita-art=
ists.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 i=
n
> bugzilla works". I know Harald has built tools and views and things to he=
lp
> out there, but we do need a .. well, a concrete proposal for how things w=
ould
> work.

Currently, the extra tooling we maintain for closing bugs and adding commen=
ts in Bugzilla
when an MR is opened is currently natively supported by GitLab. For bug tri=
agging,
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 whe=
n
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 th=
e
matrix instance used, the libQuotient version used, ... and for that, I nee=
d a
special bug reports template. Something that Bugzilla doesn't provide and w=
ithout
it, the bugs report are in many cases worthless.

I really don't think forcing every KDE project to use Bugzilla is a good id=
ea.
As long as it uses KDE infra it should be fine (compliance with our manifes=
to).
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 th=
em
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]


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