> 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 <[email protected]> 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
