Koko in KDEReview
carl at carlschwan.eu
Tue May 4 16:53:47 BST 2021
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
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?
More information about the kde-core-devel