Invent/gitlab, issues and bugzilla

[Elv1313 .]

> It is not designed to be a bug database

No, it is an issue tracker. As I mentioned in my first mail, people
have issues with software or software have issues with their features.
People don't have bugs. An issue is a different abstraction. An issue
*is not* a bug. For some projects, an issue is a good abstraction, for
yours it isn't. These little web frameworks thing developed by the
cool kids (and Google/Facebook/*Mozilla*) have millions of users and
use GitHub issues without an external bug tracker. Now, I agree with
you this will never work with Krita.

> none of the open source user support systems is usable. Me and the rest of the Krita team looked at all of them.

This is also what I have seen. Commercial ones are very nice and FLOSS
one archaic and unfriendly. Now the real problem here is that some
projects with larger non-technical userbase cannot use "issues"
because of the problems you mentioned. But saying that everyone should
use BZ because the top 10 projects need a support system on another
level of abstraction is a bit unconvincing. Don't misquote me on this.
I agree with you a powerful bug tracker is better for such projects
than issues, which would, in this case, not work.

> I have no idea what you mean with PR<-->Issues integration problem.

The things other people mentioned (close issues when PRs are merged,
links with context on hover, etc) Plus, "in the future", maybe
improvements like being able to turn an issue in a pull request when a
patch is merged. Plus, as mentionned, an unified pipeline from
creating an issue to releasing a solution with proper metadata
tracking and APIs along the way.

> how did that ever come into this discussion?

I added this to the discussion in my first message because I want to
shed light on the fact that having multiple services with different
APIs makes integrating bots harder. The idea of a development bot (or
"app", "external plugins", "add on", "unicorns") is that instead of
having all the features built-in, you have applications that interact
with other apps or other humans during the development process. This
is a way to integrate small "unix like" tools that do one thing and do
it well. But this requires deep API access into the "pipeline". Those
tools are also often targeting only one ecosystem (mergify.io is for
GitHub).

 * Chat bots to welcome new contributors and bug submitter with some
info (Microsoft uses that on GH).
 * Bots that parse backtraces and look for potential duplicates.
 * Bots that tell when a patch is considered to be ready to land
(maintainer approval, passes test, hits coverage target, etc) (like
Mergify.io)
 * Bots to remind users the devs are wating for info or auto-close
(some projects have them, I don't know the name).
 * Code coverage bots (like CodeCov.io)
 * Auto-label bots based on pull request content
 * Delete merged branches from forks
 * Classic chatbots where "@botname magic word" perform actions
 * GodBolt like bots in case of libraries
 * Bots based on OpenQA to show unexpected screenshots differences
 * EBN/Clazy issues finder providing fix-it directly in the patch GUI
 * SPAM digest bots to bundle all review comments with context because why not
 * Bots to provide links to the updated documentation for PRs
 * Bots to re-order commits or squash some commits into other
 * Bots to share AppImages/DMG/Portable_app made for all pull requests
so users can test changes.
 * Bots to integrate Launchpad Apport like telemetry data based on
backtraces issues.

In the list above, 3 problems mentioned in this thread could be solved
by "simple" bots based on the API without having to make any change to
GitLab or upgrade to EE. Note that most of the bots idea mentioned
above currently don't currently exist for GitLab, but could. A bot
based approach may or may not be a path forward for some of the
problems argued in this thread. It doesn't change the fact that GL
"issues" are not "bugs" and that GitLab doesn't have custom
comboboxes. Also notes that those "bots" are not like old Jenkins
plugins, they are external tools that use the GitLab API like a
desktop app uses syscall. This makes them easier to add and remove and
they don't make everything slower like Jenkins plugins. But this is a
technical details (and off topic for this thread, which is about
disabling GitLab issues or using them).

Now, to remind why it has something to do with *bug trackers*, it is,
again, because such tools will usually only target one ecosystem and
keeping BZ+GitLab makes it 2 ecosystems.

> Are they? Please provide hard proof.

Well, Bhushan mentioned a few groups that prefer such workflow and the
level of abstraction provided by issues compared to bugs. However, the
simple fact that GitHub has millions of projects and a lot of large
FLOSS community like FreeDesktop and Gnome moved to GitLab and their
issues is undeniable, those are facts. They had those same discussions
we are having and they chose GitLab (with issues). Looking for hard
proof from within KDE is obviously deeply flawed because if a desktop
Qt project is on GitHub and not on KDE, it is because either they
don't know about KDE or they didn't think it would be better for them
for X reasons and we don't known unless we ask each of them. Looking
from the other side (from within KDE), you only have the projects that
think moving to KDE infrastructure benefits them (like automatic
releases for KDE applications, a CI that works well for Qt (kdenlive,
ktechlab) or for longstanding KDE related apps whose maintainer moved
on and someone else wants to share some of the maintenance burden with
us to spread the costs (kdiff3)). So, no, from within, there is no
such proofs, but there is a lot of them in the larger ecosystem.

On Thu, 4 Jul 2019 at 17:11, Christoph Cullmann <christoph at cullmann.io> wrote:
>
> Hi,
>
> On 2019-07-04 22:49, Boudewijn Rempt wrote:
> > On donderdag 4 juli 2019 22:18:32 CEST Elv1313 . wrote:
> >> Ok, lots of email in the last few hours, lets recap a bit.
> >>
> >> 1. "Top" projects don't like GitLab issues because they are too
> >> simple. Can we try to make a comprehensive list of issues on a pad
> >> somewhere? So far, I see:
> >
> > I did make a comparison between bugzilla as it is current and gitlab;
> > I don't think anyone could conclude from that there is any chance of
> > gitlab's issues feature being capable of being improved to the point
> > where it can replace bugzilla. It is, simply enough, _not designed to
> > do that_. It is not designed to be a bug database, it's a developer
> > task tracker. Not a good one, but it is NOT a bug tracker. Everyone
> > should stop thinking it is. We've had enough mails today to prove that
> > beyond all doubt.
> >
> > Nobody should advocate anymore for replacing bugzilla with gitlab's
> > issues. That ship has sunk.
> >
> >> 2. For point 1.3, maybe this is where the solution is. @Boud, you
> >> mention that Krita "ask" failed. Can you provide more insight here on
> >> why?
> >
> > It failed, as I have said, because the software was modeled on
> > stackoverflow. That is, on users helping each other. Users cannot help
> > other users with support questions; they do not have the knowledge for
> > that.
> >
> >> Is there anything to learn so we can try better?
> >
> > A good user support system is smart and offers a shortlist of most
> > common answers to any question. It does not require logging in for the
> > user. Zoho helpdesk might be a good user support system; none of the
> > open source user support systems is usable. Me and the rest of the
> > Krita team looked at all of them.
> >
> >> How about
> >> redirecting users directly to a ticket system for top-10 projects?
> >> Ticket systems are overkill (and problematic) for 95% of the KDE
> >> projects, but seem a step forward for larger projects. Or maybe send
> >> people to "a forum" first? For my largest non-KDE project (AwesomeWM),
> >> when we switched to GitHub (from FlySpray), we updated the contact
> >> page of the website to point to StackOverflow.com, SuperUser.com and
> >> Reddit above the GitHub Issue link. This worked fine for a relatively
> >> medium-large user base (of geeks).
> >
> > AwesomeWM's userbase is exceptionally technically capable. Our users
> > are just about capable of shouting out on Reddit things like "Help! I
> > have an issue! Help me! I have an assignment due tomorrow!" Without
> > giving more detail.
> >
> >> 3. The login (identity.kde.org) issue. Maybe I am not on enough
> >> mailing lists, but what is the situation regarding generic OAuth2
> >> login for a subset of non-developer services? Is it only an
> >> integration issue or a political one? Being able to login with
> >> Google/Facebook/GitHub/Yahoo/Microsoft/GitLab/Gnome(?!) accounts with
> >> a path to upgrade to "proper" account seems to currently be the
> >> popular and future proof way to handle this. This is better from a
> >> security standpoint because all of them support 2 factor
> >> authentication in a way *normal people* can understand (aka, a
> >> notification on Android phones). Of course it doesn't help with GPG
> >> and SSH public key wallets and other dev related concerns. That's not
> >> relevant for most users.
> >
> > I don't know; I do know that even the least technically able of my
> > users has managed to get a bugs.kde.org account. A KDE Identity
> > account so they can post on the Forum is a far bigger challenge.
> >
> >> 4. For point 1.5, this isn't really solving anything. Sure, a better
> >> BZ with all the powerful features would be nice. It would not solve
> >> the PR<->Issues integration problems at all, which still leaves half
> >> of the people here unsatisfied.
> >
> > I have no idea what you mean with PR<-->Issues integration problem.
> >
> >> It would not be welcoming to projects
> >> looking to move into the incubator because they are used to a more
> >> integrated pipeline.
> >
> > Are they? Please provide hard proof.
> >
> >> It would also leave the whole problem of slowly
> >> making the services more bot friendly, which is the future.
> >
> > What do you mean with that?
> >
> >> 4.1 This would leave the sequestration of BKO and IKO into 2
> >> ecosystems. This makes bots more complex and makes porting good open
> >> source bots such as mergify.io even harder since it would be more
> >> painful than just a GitHub<->GitLab API compat (or if they ever
> >> support GitLab). Bots are a solution to many of the problem outlined
> >> here, such as when is a pull request acceptable to merge or some magic
> >> rebase/squash/fixup bots.
> >
> > To me, that sounds like a lot of very technical gibberish, and as far
> > as I can understand it, totally irrelevant. What is "mergify.io" and
> > how did that ever come into this discussion?
>
> I wanted to write a lengthy reply, but Boud got already all my points
> covered,
> I just agree.
>
> For mergify.io and other automation:
>
> I think the bots you want for the development stuff, like automating
> merge request
> reviews (are all tests fine, ...) are good to have, but this is
> unrelated to
> user bug reports. I doubt it will hurt to have user bug reports on a
> different
> system for this, as long as we have trivial integration like "I merge a
> thing with
> a BUG.... keyword => the bug gets resolved and the merge request
> linked").
>
> Greetings
> Christoph
>
> --
> Ignorance is bliss...
> https://cullmann.io | https://kate-editor.org