Invent/gitlab, issues and bugzilla

[Christoph Cullmann]

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