Le mardi, mai 4, 2021 4:53 PM, Adriaan de Groot <gr...@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]