Re: Invent/gitlab, issues and bugzilla

[Elv1313 .]

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? Sa far, I see:
1.1 It doesn't allow custom combo boxes like BZ/RedMine which then
forces manual abuse of labels. This probably runs a bit deep and
affect the search.
1.2 It doesn't allow fine grained issues tree where dependencies and
relationship can be tracked "well enough".
1.3 It doesn't allow a "walled garden" to separate technical
discussions from support.
1.4 Someone should chat with GitLab about this to see what they think
about adding some EE features into CE.
1.5 There is BZ 6, 7 and 8 in various level of development or planning
which seem good

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? Is there anything to learn so we can try better? 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).

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.

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. It would not be welcoming to projects
looking to move into the incubator because they are used to a more
integrated pipeline. It would also leave the whole problem of slowly
making the services more bot friendly, which is the future.
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.

On Thu, 4 Jul 2019 at 15:39, Boudewijn Rempt  wrote:
>
> On donderdag 4 juli 2019 21:32:59 CEST Ben Cooksley wrote:
>
> > With regards to Identity, I'm well aware it has its issues - it was
> > originally designed as a system for developers and other contributors (so
> > not users) and is now many years old.
> >
> > It's trying to do a job it was never designed to do, in a world that is
> > quite different from the one it was originally created for. We do have
> > plans to replace it, but getting time to seriously look into those is quite
> > difficult.
>
> It's mostly outside KDE's own infrastructure that we get those complaints -- 
> people on IRC, Twiter, Reddit and so on complaining they just cannot figure 
> out how the heck they can make it possible for themselves to login on the 
> forum.
>
> --
> https://www.valdyas.org | https://www.krita.org
>
>

Re: Invent/gitlab, issues and bugzilla

[Boudewijn Rempt]

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?


-- 
https://www.valdyas.org | https://www.krita.org

Re: Invent/gitlab, issues and bugzilla

[Boudewijn Rempt]

On donderdag 4 juli 2019 20:42:31 CEST Martin Flöser wrote:
> 
> Boud pretty much describes the problem large projects (krita, kwin, 
> plasma) have with bugzilla. We don't use bugzilla to handle bug reports, 
> but to somehow manage all the reports we get, to survive. I blogged 
> about these issues years ago, I did statistics for KWin showing that > 
> 90 % of the incoming bug reports are not bug reports, but rather 
> duplicates, user support, etc. The situation hasn't changed much over 
> the years. Reading Boud's comments it looks like the situation became 
> much worse for krita lately and I do not want to swap with him.

For the past six months or so, Krita is the KDE product which gets the most bug 
reports. We're also seeing a continuation of the real rise in downloads, social 
media traffic and user base. That results in lots more interaction with 
end-users, which I normally like. I like my users. The big difference between 
working on Krita and all other jobs I've ever had is that when I work on Krita, 
my work ends up being used.

> Obviously for any large project the idea of swapping to an inferior 
> system (which gitlab seems to be, haven't used it yet) is a horrible 
> idea. But that's not the problem. The problem is that users interact 
> with developers directly. The user goes to bugzilla or gitlab issues and 
> reports a support request. Instead of friendly user support he gets a 
> grumpy third level support answer that this is not an issue. No help, 
> frustrated user and frustrated dev who just wasted another minute on 
> bugzilla to handle user support.

I try not to be grumpy... But we've closed ask.krita.org and I've retired from 
reddit and we don't do support on Twitter -- because it's no longer manageable.

> No company would allow to have Boud handle user support. That's insane. 
> He's product owner, chief technologies, call him whatever you want, but 
> he is not first level user supporter.

In fact, I hired one of the volunteers who spent all her time helping people to 
help me fix bugs. It's working out great, and I've hired a second bug-fixing 
minion, and now the first minion (they choose their titles) is trying to help 
to figure out how to plug the user support gap.

> That's the problem we have to face. Whether we use bugzilla or gitlab 
> issues for internal issues is irrelevant. 

Not totally irrelevant. Gitlab just does not cut the mustard for tracking bugs. 
It was not designed for that, it cannot handle that. The whole discussion about 
ditching bugzilla and moving to gitlab issues is, as far as I am concerned, a 
has-been. It's over. You don't point people at something like invent.kde.org 
and ask them to figure out how to report a bug.

> What is important is that we a
> get users to use an adequate user support forum and not bugzilla or 
> gitlab issues. Once we get the shit reports out of our bug tracker, 
> everything looks different.

I'm not very hopeful about that happening, though.

> Right now from KWin perspective I would say "hell no!" to the idea of 
> using gitlab issues. But a better tool for development which gitlab 
> issue seems to be is something I would like to have. Because for 
> development planing I never really liked bugzilla. Although it might be 
> that it was just too useless due to all the invalid bug reports.

Yes, development planning is not what bugzilla is for. We need a four-stage 
system:

1. User support system. User reports an issue, gets a canned answer in 90% of 
the cases. In 10% of the cases, they have found a bug.
2. Bug tracker. Those user bugs, and the bugs the developers find are 
registered. With the right component, version, all the data we can get. Once 
the bug gets assigned, we move to system 3.
3. Task system. Information about one or more bugs gets consolidated into one 
task, and a plan is formulated. The task gets updated with commits, comments 
and so on during the implementation phase. It ends in  review request or merge 
request...
4. There's a merge request or review request, and once it gets accepted or 
merged, 3 is informed, 2 is informed and 1 is informed.

> My suggestion is to address the user support and then look into whether 
> we want to keep bugzilla or switch to gitlab issues.

For me it's clear: gitlab issues can, barely, replace Phabricator's tasks. They 
cannot replace a bug tracker. 

-- 
https://www.valdyas.org | https://www.krita.org

Re: 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 

Re: Invent/gitlab, issues and bugzilla

[Eike Hein]

I think this discussion has sort of strayed, if understandably so. Maybe this 
helps:

- A lot of projects currently use Phabricator tasks and rely on them heavily.
- The GitLab equivalent are Issues.
- We're trying to replace Phabricator with GitLab.
- If Issues are disabled, we can't import the Phab tasks.

This is lossy and unacceptable. I expect to find my Phab tasks in GitLab when 
my projects are migrated, and getting those migration ducks in a row is, in my 
mind, primarily why they aren't yet.

As for whether Issues can be used for bug reports, that's a seperate policy 
dimension from the above. We didn't write rules on this for Phabricator, and 
maybe we don't need to for GitLab, either, but at the same time it's very clear 
that KDE projects need to have a presence on Bugzilla.

The relevant part of the KDE Manifesto isn't anything about hosting 
infrastructure, it's the "Common Ownership" one: Without a unified bug tracker, 
it's not possible to conveniently reassign bugs between products or do queries 
against the entire database. We do this and rely on this all the time, and our 
software and community are better and stronger for it. Projects that would 
trade this benefit aren't well-integrated in the sense of understanding what 
becoming part of KDE truly gets them, and then we should do a better job 
telling them, because it's pretty awesome.

If we migrate bug tracking at a later time, it should be in one swoop. I see 
this as a separate project from Phab-to-GitLab at this time.

With my maintainer hat on personally I also agree with Boud that a line between 
dev task tracking and bug reports is healthy for larger projects. They seem to 
be smart enough to figure that out on their own, though. 

Such a separation doesn't necessarily mean needing two web apps. It does 
however mean figuring out our needs for both types of activity, our needs for 
how they need to be seperated, and checking if the One True App meets all of 
those needs. And if it doesn't, looking into talking to its developers to 
improve it. On that note I'll add that one of the major reasons we are 
migrating to GitLab is that we can actually talk to them and have them respond: 
This is exciting and fits the pattern of KDE making successful tooling choices 
based on strong upstream relations. Let's not forget that and get burned out 
over internal haggling.

This requires a process, and a much better one than shouting at each other in a 
convuluted mailing list thread. :)


Cheers,
Eike

Re: Invent/gitlab, issues and bugzilla

[Martin Flöser]

Hi all,

I just read through the complete thread and thought I want to add a 
little bit, because I think we miss the big picture.


Boud pretty much describes the problem large projects (krita, kwin, 
plasma) have with bugzilla. We don't use bugzilla to handle bug reports, 
but to somehow manage all the reports we get, to survive. I blogged 
about these issues years ago, I did statistics for KWin showing that > 
90 % of the incoming bug reports are not bug reports, but rather 
duplicates, user support, etc. The situation hasn't changed much over 
the years. Reading Boud's comments it looks like the situation became 
much worse for krita lately and I do not want to swap with him.


Obviously for any large project the idea of swapping to an inferior 
system (which gitlab seems to be, haven't used it yet) is a horrible 
idea. But that's not the problem. The problem is that users interact 
with developers directly. The user goes to bugzilla or gitlab issues and 
reports a support request. Instead of friendly user support he gets a 
grumpy third level support answer that this is not an issue. No help, 
frustrated user and frustrated dev who just wasted another minute on 
bugzilla to handle user support.


No company would allow to have Boud handle user support. That's insane. 
He's product owner, chief technologies, call him whatever you want, but 
he is not first level user supporter.


That's the problem we have to face. Whether we use bugzilla or gitlab 
issues for internal issues is irrelevant. What is important is that we 
get users to use an adequate user support forum and not bugzilla or 
gitlab issues. Once we get the shit reports out of our bug tracker, 
everything looks different.


Right now from KWin perspective I would say "hell no!" to the idea of 
using gitlab issues. But a better tool for development which gitlab 
issue seems to be is something I would like to have. Because for 
development planing I never really liked bugzilla. Although it might be 
that it was just too useless due to all the invalid bug reports.


My suggestion is to address the user support and then look into whether 
we want to keep bugzilla or switch to gitlab issues.


Cheers
Martin

Am 2019-07-04 19:26, schrieb Boudewijn Rempt:

On donderdag 4 juli 2019 19:19:17 CEST Nate Graham wrote:

On 7/4/19 11:06 AM, Christoph Cullmann wrote:
> Actually, do we really want that every user bug reporter opens an
> account on invent.kde.org?
>
> I actually think the split of accounts between phabricator/gitlab vs.
> bugzilla is no bad but a good feature.

It would definitely solve that problem, but there are a few practical
problems with this:

- People would continue to need two accounts (BKO and 
identity/invent),


Like I said in my other mail, it's not hugely important for the kind
of reporter who is not already a developer, and who knows, maybe that
can be fixed as well. It's not like Identity is universally beloved.


and the systems wouldn't be integrated as well as thy could be, which
negates some of the purported advantages of moving to GitLab in the
first place


But that's the _point_. There needs to be a kind of division between
user issue reporting and developer/development activity.


- GitLab Issues are lacking some of the features of Phabricator Tasks
such as parent & sub-task tracking



Yes, gitlab issues is an all-round aenemic feature, but I could live
with it for a tasks replacement, but not for a issue reporter
replacement.


- Using GitLab Issues exclusively to replace Phab Tasks will confuse
users who are accustomed to using Issues for bug reporting in other
projects (though I suppose this could be remedied by renaming "Issues"
to "Tasks" in the UI, and implementing a template that explicitly says
"Don't use this to report bugs")


And users get would sent to bugs.kde.org anyway; no normal user is
going to something called "invent.kde.org" to report a bug, unless
there's very specific guidancce to send them there.

Re: Invent/gitlab, issues and bugzilla

[Ben Cooksley]

On Fri, 5 Jul 2019, 05:08 Volker Krause,  wrote:

> On Thursday, 4 July 2019 17:43:06 CEST Boudewijn Rempt wrote:
> > On donderdag 4 juli 2019 13:02:24 CEST Kai Uwe Broulik wrote:
> > > I complained about the same thing but I was told you can replicate most
> > > of those (OS, platform, etc) using tags/badges and project structures.
> > > There isn't a 1:1 mapping of fields and tech we got used to from
> Bugzilla.
> >
> > And then I thought to check how GIMP is handling this. It's not pretty:
> four
> > pages of label definitions (and keep in mind that all labels are
> available
> > both to merge requests and issues). Creating a query when there are so
> many
> > labels is exceedingly hard, as I imagine actually managing them and
> tagging
> > reports with them. See https://gitlab.gnome.org/GNOME/gimp/-/labels
> >
> > A second problem here is that these labels are defined _per project_.
> That
> > means that any common way of handling bugs among KDE projects will
> > disappear.
>
> On top of that, anything requiring manual per-repo setup isn't going to
> work
> for projects with split repos, such as PIM (50+) or Frameworks (70+).
>

Small correction here - From my understanding you can define labels at the
group level, which are then shared with all the underlying subgroups and
projects (repositories).

At some point depending on how things go I expect us to need to define some
labels at varying group levels.


> > Sorry, but I don't see any way this is going to end well. KDE projects
> > should not use the gitlab issues feature for bug reports. Use of the
> issues
> > feature should be reserved for replacing the phabricator tasks
> > functionality. KDE should continue to use bugzilla.
>
> From what I have seen of Gitlab so far (which I like in general as it
> removes
> the error-prone arcanist from my workflow), I have to agree with that.
>
> Regards,
> Volker


Cheers,
Ben

Re: 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 

Re: Invent/gitlab, issues and bugzilla

[Boudewijn Rempt]

On donderdag 4 juli 2019 21:32:59 CEST Ben Cooksley wrote:

> With regards to Identity, I'm well aware it has its issues - it was
> originally designed as a system for developers and other contributors (so
> not users) and is now many years old.
> 
> It's trying to do a job it was never designed to do, in a world that is
> quite different from the one it was originally created for. We do have
> plans to replace it, but getting time to seriously look into those is quite
> difficult.

It's mostly outside KDE's own infrastructure that we get those complaints -- 
people on IRC, Twiter, Reddit and so on complaining they just cannot figure out 
how the heck they can make it possible for themselves to login on the forum.

-- 
https://www.valdyas.org | https://www.krita.org

Re: Invent/gitlab, issues and bugzilla

[Ilmari Lauhakangas]

Elv1313 . kirjoitti 5.7.2019 klo 1.59:

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.


We have had this sort of integration in LibreOffice (TDF) Bugzilla since 
the early 2010s as far as I know. BZ report numbers get linkified on our 
gerrit patch review and our various git web interfaces. Reports get 
automatic comments and whiteboard items upon commits. Changing the state 
to RESOLVED does not happen automatically, but that is because of very 
good reasons: some issues might take multiple commits/patches. Some easy 
hacks might stay alive for dozens of commits.


Bugzilla has had powerful APIs since forever and they are clearly 
wanting to keep improving them. Quoting from the BZ 7 UX roadmap:


Integrations

Bugzilla GraphQL API v1
GitHub integration
  Webhook support: Automatically attach pull request links and close 
bugs without a 3rd party bot


Regarding logins, if you visit https://bugzilla.mozilla.org/ you will 
notice it supports logging in with a GitHub account.


Single sign-on should be doable in any case, even if BZ would not offer 
support for a specific service out of the box.


The topic of managing low-quality or duplicate reports came up again. I 
think I mentioned this earlier in some other thread, but it bears 
repeating Mozilla is actively developing a tool to help with this and 
other bug management tasks: https://github.com/mozilla/bugbug


See "duplicate - The aim of this classifier is to detect duplicate bugs" 
etc.


Ilmari

Re: Invent/gitlab, issues and bugzilla

[Ben Cooksley]

On Fri, 5 Jul 2019, 05:19 Boudewijn Rempt,  wrote:

> On donderdag 4 juli 2019 19:02:10 CEST Nate Graham wrote:
> > On 7/4/19 10:39 AM, Boudewijn Rempt wrote:
> > > Is it really true that gitlab makes reporting bugs easier for our
> users? I.e., does it offer easier login, an easier way to add screen shots
> and screen recordings or crash logs?
> >
> > In my experience, yes. Being able to use a single account for everything
> > is a big benefit
>
> But is that also true for users? If someone uses a KDE application and
> wants to report a bug for the first time, which is easier? Making a
> bugzilla account, or making a KDE identity account and using that for
> gitlab?
>
> > . And being able to add multiple images and files inline
> > via drag-and-drop is a huge improvement over Bugzilla IMO. Then again if
> > Bugzilla 6 offers this, that will remove one advantage of GitLab issues.
>
> Yes... So I don't think that is all that urgent.
>
> > > Is it really true that gitlab makes it easier for our users to make
> reports of a better quality? Like, better wizards, forms, support for
> smarter templates, more ways to cross-check a bug report with other bug
> reports, or cross-check the internal consistency? Is it easier for a user
> reporting a bug on gitlab to tell us which OS, version of OS, version of
> the application they are using?
> > >
> > > Does gitlab offer convenience features for our users like replying by
> email? (I know that some people think email is on the way out, but in real
> life, everyone has email -- and if it were going out -- is there
> integration with instant messaging?) Does gitlab make it easier to be
> notified of events related to the issue?
> >
> > I'm not sure about these.
>
> Well, those are important questions :-)
>
>
> > > We all know that gitlab has a rich text editor. This is modern, but
> how important is that, actually? And how important is it to have a rich
> text editor in our issue reporting system right now? Are we experience a
> decline in the number of user reports because more and more people don't
> want to use bugzilla?
> > >
> >
> > Anecdotally, yes. I very commonly hear users on social media write and
> > say things like "I don't file KDE bugs anymore because Bugzilla is
> > ancient and incomprehensible". Though to be fair, they also commonly say
> > that it's because we don't do a good enough job triaging bugs, or that
> > KDE developers are too mean and abrasive when dealing with users, so
> > take it with a grain of salt.
>
>
> Given that I'm inundated with bug reports for Krita, I'll subscribe to
> that grain of salt -- I just don't believe that people who haven't got any
> KDE login anyway, for people who just use an application, experience a
> crash and then want to report a bug are and then arrive at bugs.kde.org
> decide to not report the bug because the they cannot login with the KDE
> identity they don't have yet. I don't believe that my users get confused
> even if they have a KDE Identity (for the forum, and KDE Identity is the
> biggest problem we have with the forum, before search, threading, email) --
> most people who actually report bugs seem to accept this.
>

Interesting, first time I've heard any of this mentioned.

With regards to Identity, I'm well aware it has its issues - it was
originally designed as a system for developers and other contributors (so
not users) and is now many years old.

It's trying to do a job it was never designed to do, in a world that is
quite different from the one it was originally created for. We do have
plans to replace it, but getting time to seriously look into those is quite
difficult.

Cheers,
Ben


> And just imagine being a non-technical user who has to find their to
> reporting a bug on a KDE project, who starts at
> https://invent.kde.org/public/ -- there's no help at all!
>
>
>
> --
> https://www.valdyas.org | https://www.krita.org
>
>
>

Re: Invent/gitlab, issues and bugzilla

[Kevin Ottens]

Hello,

On Thursday, 4 July 2019 19:07:20 CEST Volker Krause wrote:
> On Thursday, 4 July 2019 17:43:06 CEST Boudewijn Rempt wrote:
> > Sorry, but I don't see any way this is going to end well. KDE projects
> > should not use the gitlab issues feature for bug reports. Use of the
> > issues
> > feature should be reserved for replacing the phabricator tasks
> > functionality. KDE should continue to use bugzilla.
> 
> From what I have seen of Gitlab so far (which I like in general as it
> removes the error-prone arcanist from my workflow), I have to agree with
> that.

Count me on that particular group. It's just not the same volumes between 
project tasks and bugs. Besides I agree with Boud that it's good for the 
developers to have a space undisturbed from the support hotline. It's fine for 
tasks in gitlab/phab to refer bugs in bugzilla IMO.

Regards.
-- 
Kevin Ottens, http://ervin.ipsquad.net


signature.asc
Description: This is a digitally signed message part.

Re: Invent/gitlab, issues and bugzilla

[Boudewijn Rempt]

On donderdag 4 juli 2019 13:02:24 CEST Kai Uwe Broulik wrote: 
> I complained about the same thing but I was told you can replicate most 
> of those (OS, platform, etc) using tags/badges and project structures. 
> There isn't a 1:1 mapping of fields and tech we got used to from Bugzilla.

And then I thought to check how GIMP is handling this. It's not pretty: four 
pages of label definitions (and keep in mind that all labels are available both 
to merge requests and issues). Creating a query when there are so many labels 
is exceedingly hard, as I imagine actually managing them and tagging reports 
with them. See https://gitlab.gnome.org/GNOME/gimp/-/labels 

A second problem here is that these labels are defined _per project_. That 
means that any common way of handling bugs among KDE projects will disappear.

Sorry, but I don't see any way this is going to end well. KDE projects should 
not use the gitlab issues feature for bug reports. Use of the issues feature 
should be reserved for replacing the phabricator tasks functionality. KDE 
should continue to use bugzilla.

-- 
https://www.valdyas.org | https://www.krita.org

Re: Invent/gitlab, issues and bugzilla

[Christoph Cullmann]

On 2019-07-04 19:02, Nate Graham wrote:

On 7/4/19 10:39 AM, Boudewijn Rempt wrote:
Is it really true that gitlab makes reporting bugs easier for our 
users? I.e., does it offer easier login, an easier way to add screen 
shots and screen recordings or crash logs?


In my experience, yes. Being able to use a single account for
everything is a big benefit. And being able to add multiple images and
files inline via drag-and-drop is a huge improvement over Bugzilla
IMO. Then again if Bugzilla 6 offers this, that will remove one
advantage of GitLab issues.


I actually think the state on https://bugzilla.mozilla.org/ is quiet 
usable, they tuned it the last X years.

But yes, a lot of this is missing in the current Bugzilla 5 :(




Is it really true that gitlab makes it easier for our users to make 
reports of a better quality? Like, better wizards, forms, support for 
smarter templates, more ways to cross-check a bug report with other 
bug reports, or cross-check the internal consistency? Is it easier for 
a user reporting a bug on gitlab to tell us which OS, version of OS, 
version of the application they are using?


Does gitlab offer convenience features for our users like replying by 
email? (I know that some people think email is on the way out, but in 
real life, everyone has email -- and if it were going out -- is there 
integration with instant messaging?) Does gitlab make it easier to be 
notified of events related to the issue?


I'm not sure about these.


We all know that gitlab has a rich text editor. This is modern, but 
how important is that, actually? And how important is it to have a 
rich text editor in our issue reporting system right now? Are we 
experience a decline in the number of user reports because more and 
more people don't want to use bugzilla?




Anecdotally, yes. I very commonly hear users on social media write and
say things like "I don't file KDE bugs anymore because Bugzilla is
ancient and incomprehensible". Though to be fair, they also commonly
say that it's because we don't do a good enough job triaging bugs, or
that KDE developers are too mean and abrasive when dealing with users,
so take it with a grain of salt.


Actually, do we really want that every user bug reporter opens an 
account on invent.kde.org?


I actually think the split of accounts between phabricator/gitlab vs. 
bugzilla is no bad but a good feature.


Greetings
Christoph

--
Ignorance is bliss...
https://cullmann.io | https://kate-editor.org

Re: Invent/gitlab, issues and bugzilla

[Ilmari Lauhakangas]

Nate Graham kirjoitti 4.7.2019 klo 20.02:

On 7/4/19 10:39 AM, Boudewijn Rempt wrote:
Is it really true that gitlab makes reporting bugs easier for our 
users? I.e., does it offer easier login, an easier way to add screen 
shots and screen recordings or crash logs?


In my experience, yes. Being able to use a single account for everything 
is a big benefit. And being able to add multiple images and files inline 
via drag-and-drop is a huge improvement over Bugzilla IMO. Then again if 
Bugzilla 6 offers this, that will remove one advantage of GitLab issues.


Drag'n'drop & multi-upload is planned for BZ 7: 
https://github.com/bugzilla/bugzilla-ux/wiki/Bugzilla-7-Roadmap


It would be cool, if entities like KDE e.V. and TDF could team up and 
sponsor BZ UX improvements so we'd get to BZ 7 & 8 goals faster. I'm not 
sure about the bureaucracy to make this happen, though.


BZ is also easier to extend under the hood now as it has started using 
Mojolicious framework. It will allow getting rid of the CGI dependency. 
Presentation about this: https://www.youtube.com/watch?v=0jIk3s7GsEo


Ilmari

Re: Invent/gitlab, issues and bugzilla

[Michael Pyne]

On Thu, Jul 04, 2019 at 06:22:11AM +0300, Ilmari Lauhakangas wrote:
> Nate Graham kirjoitti 3.7.2019 klo 21.23:
> > On 7/3/19 11:53 AM, Albert Astals Cid wrote:
> >> If the new is much better than the old, let's just remove the old.
> >>
> >> As said, having two things that do the same is just confusing for 
> >> everyone.
> > 
> > I would tend to agree, and having two is super confusing. In general, 
> > people who have reported bugs on both Bugzilla and GitHub or GitLab seem 
> > to agree that Bugzilla's UX is inferior. However I don't believe we've 
> > officially trialed GitLab Issues and investigated what missing features 
> > need to be added before we can migrate to it. Maybe the time to do that 
> > is now, as a part of the general GitLab evaluation and migration period.
> > 
> > Personally I find GitLab Issues to offer a vastly superior UX for bug 
> > reporting compared to Bugzilla. However the UX for bug management and 
> > triaging is not as granular. For example I still haven't figured out a 
> > way to create a saved search for "all Issues opened in the last 24 hours 
> > across all projects". And it would be nice to have some kind of overview 
> > similar to https://bugs.kde.org/weekly-bug-summary.cgi.
> 
> The upcoming Bugzilla version 6 will have a vastly superior UX to BZ 5: 
> https://github.com/bugzilla/bugzilla-ux/wiki/Bugzilla-6-Roadmap
> 
> With support from the BZ team, Kohei Yoshino has essentially solved BZ 
> UX (this includes drafting plans for the future) and I am immensely 
> grateful to him.
> 
> The underlying functionality will remain superior to GitLabs and hubs as 
> it has been for years.

I couldn't help but to notice that the feature plan you refer to, for
how Bugzilla now has a superior UX drafting future feature plans than
Gitlab/Github, is actually hosted in Github rather than Bugzilla.

The irony is that BZ 6 really will have key features that will be handy
for developers, especially around search. E.g. from the @BugzillaUX
Twitter I see examples of a search for bugs fixed in $CURRENT_RELEASE
[1] and a search for bugs fixed "this month" (i.e. relative date) [2].

All the same, Gitlab issue tracker is certainly good enough for most
developers, more convenient for some developers, and better integrated into
the rest of the workflows Gitlab would support (merge requests, quick
actions from commit messages).

As a personal example, I'd point to
https://invent.kde.org/kde/kdesrc-build/issues/27 where Gitlab itself
was able to recognize and link to the relevant merge request. Had I
merged that exact MR to implement the issue, Gitlab would even have been
able to automatically have closed the issue. With a bit more discipline
I could have even done things like link to a specific milestone, but
kdesrc-build isn't a large enough effort to warrant that level of
detail.

I'm not sure how to bridge that gap between small projects like mine vs.
our larger efforts, but it seems to me that Gitlab is good enough for
many of our projects, while Bugzilla remains preferable for projects
that have high numbers of bugs to triage and sort through and developers
willing to learn its more advanced capabilities.

But the same thing that makes Bugzilla so powerful seems likely to
continue to make it harder for new contributors (especially contributors
used to a Github model) and so I'd be leery about making it a mandatory
user touchpoint for projects that have adopted Gitlab, at least as it
stands today. BZ 6 may improve this enough to make it feasible for new
contributors and then it would "just" be a discussion about how much the
potential integration benefits with the rest of Gitlab would be worth
balanced against the large migration effort that would seem needed if
we were to point users away from Bugzilla.

Whatever we do, we should remain mindful of our goal to be able to
onboard new contributors and I think those new contributors will come in
more and more over time with a familiarity with the Github/Gitlab model
and that we may have to find ways ourselves to adapt to that, even if
it's nothing more than having a way to "incubate" new contributors in
graduated steps to what we're using.

Regards,
 - Michael Pyne

[1] https://twitter.com/triagegirl/status/1134554219766112256
[2] https://twitter.com/triagegirl/status/1139278780881444864

Re: Invent/gitlab, issues and bugzilla

[Nate Graham]

On 7/4/19 11:06 AM, Christoph Cullmann wrote:
Actually, do we really want that every user bug reporter opens an 
account on invent.kde.org?


I actually think the split of accounts between phabricator/gitlab vs. 
bugzilla is no bad but a good feature.


It would definitely solve that problem, but there are a few practical 
problems with this:


- People would continue to need two accounts (BKO and identity/invent), 
and the systems wouldn't be integrated as well as thy could be, which 
negates some of the purported advantages of moving to GitLab in the 
first place


- GitLab Issues are lacking some of the features of Phabricator Tasks 
such as parent & sub-task tracking


- Using GitLab Issues exclusively to replace Phab Tasks will confuse 
users who are accustomed to using Issues for bug reporting in other 
projects (though I suppose this could be remedied by renaming "Issues" 
to "Tasks" in the UI, and implementing a template that explicitly says 
"Don't use this to report bugs")



Nate

Re: Invent/gitlab, issues and bugzilla

[Boudewijn Rempt]

On donderdag 4 juli 2019 19:02:10 CEST Nate Graham wrote:
> On 7/4/19 10:39 AM, Boudewijn Rempt wrote:
> > Is it really true that gitlab makes reporting bugs easier for our users? 
> > I.e., does it offer easier login, an easier way to add screen shots and 
> > screen recordings or crash logs?
> 
> In my experience, yes. Being able to use a single account for everything 
> is a big benefit

But is that also true for users? If someone uses a KDE application and wants to 
report a bug for the first time, which is easier? Making a bugzilla account, or 
making a KDE identity account and using that for gitlab?

> . And being able to add multiple images and files inline 
> via drag-and-drop is a huge improvement over Bugzilla IMO. Then again if 
> Bugzilla 6 offers this, that will remove one advantage of GitLab issues.

Yes... So I don't think that is all that urgent. 

> > Is it really true that gitlab makes it easier for our users to make reports 
> > of a better quality? Like, better wizards, forms, support for smarter 
> > templates, more ways to cross-check a bug report with other bug reports, or 
> > cross-check the internal consistency? Is it easier for a user reporting a 
> > bug on gitlab to tell us which OS, version of OS, version of the 
> > application they are using?
> > 
> > Does gitlab offer convenience features for our users like replying by 
> > email? (I know that some people think email is on the way out, but in real 
> > life, everyone has email -- and if it were going out -- is there 
> > integration with instant messaging?) Does gitlab make it easier to be 
> > notified of events related to the issue?
> 
> I'm not sure about these.

Well, those are important questions :-)


> > We all know that gitlab has a rich text editor. This is modern, but how 
> > important is that, actually? And how important is it to have a rich text 
> > editor in our issue reporting system right now? Are we experience a decline 
> > in the number of user reports because more and more people don't want to 
> > use bugzilla?
> > 
> 
> Anecdotally, yes. I very commonly hear users on social media write and 
> say things like "I don't file KDE bugs anymore because Bugzilla is 
> ancient and incomprehensible". Though to be fair, they also commonly say 
> that it's because we don't do a good enough job triaging bugs, or that 
> KDE developers are too mean and abrasive when dealing with users, so 
> take it with a grain of salt.


Given that I'm inundated with bug reports for Krita, I'll subscribe to that 
grain of salt -- I just don't believe that people who haven't got any KDE login 
anyway, for people who just use an application, experience a crash and then 
want to report a bug are and then arrive at bugs.kde.org decide to not report 
the bug because the they cannot login with the KDE identity they don't have 
yet. I don't believe that my users get confused even if they have a KDE 
Identity (for the forum, and KDE Identity is the biggest problem we have with 
the forum, before search, threading, email) -- most people who actually report 
bugs seem to accept this.

And just imagine being a non-technical user who has to find their to reporting 
a bug on a KDE project, who starts at https://invent.kde.org/public/ -- there's 
no help at all!



-- 
https://www.valdyas.org | https://www.krita.org

Re: Invent/gitlab, issues and bugzilla

[Boudewijn Rempt]

On donderdag 4 juli 2019 17:54:23 CEST Nate Graham wrote:

> - bugs.kde.org currently offers a subpar UX for users reporting issues, 
> compared to GitHub/GitLab/potentially the future Bugzilla 6 upgrade.

Um, actually, now that I think of it, that also needs a bit of substantiation. 
What are the things that would make gitlab offer a better issue reporting 
experience for users?

Is it really true that gitlab's UX is less frightening for our non-technical 
users? How easy is it to actually find the place to file a bug against GIMP 
starting from gitlab.gnome.org?

Is it really true that gitlab makes reporting bugs easier for our users? I.e., 
does it offer easier login, an easier way to add screen shots and screen 
recordings or crash logs?

Is it really true that gitlab makes it easier for our users to make reports of 
a better quality? Like, better wizards, forms, support for smarter templates, 
more ways to cross-check a bug report with other bug reports, or cross-check 
the internal consistency? Is it easier for a user reporting a bug on gitlab to 
tell us which OS, version of OS, version of the application they are using?

Does gitlab offer convenience features for our users like replying by email? (I 
know that some people think email is on the way out, but in real life, everyone 
has email -- and if it were going out -- is there integration with instant 
messaging?) Does gitlab make it easier to be notified of events related to the 
issue?

We all know that gitlab has a rich text editor. This is modern, but how 
important is that, actually? And how important is it to have a rich text editor 
in our issue reporting system right now? Are we experience a decline in the 
number of user reports because more and more people don't want to use bugzilla?

-- 
https://www.valdyas.org | https://www.krita.org

Re: Invent/gitlab, issues and bugzilla

[Volker Krause]

On Thursday, 4 July 2019 17:43:06 CEST Boudewijn Rempt wrote:
> On donderdag 4 juli 2019 13:02:24 CEST Kai Uwe Broulik wrote:
> > I complained about the same thing but I was told you can replicate most
> > of those (OS, platform, etc) using tags/badges and project structures.
> > There isn't a 1:1 mapping of fields and tech we got used to from Bugzilla.
> 
> And then I thought to check how GIMP is handling this. It's not pretty: four
> pages of label definitions (and keep in mind that all labels are available
> both to merge requests and issues). Creating a query when there are so many
> labels is exceedingly hard, as I imagine actually managing them and tagging
> reports with them. See https://gitlab.gnome.org/GNOME/gimp/-/labels
> 
> A second problem here is that these labels are defined _per project_. That
> means that any common way of handling bugs among KDE projects will
> disappear.

On top of that, anything requiring manual per-repo setup isn't going to work 
for projects with split repos, such as PIM (50+) or Frameworks (70+).

> Sorry, but I don't see any way this is going to end well. KDE projects
> should not use the gitlab issues feature for bug reports. Use of the issues
> feature should be reserved for replacing the phabricator tasks
> functionality. KDE should continue to use bugzilla.

>From what I have seen of Gitlab so far (which I like in general as it removes 
the error-prone arcanist from my workflow), I have to agree with that.

Regards,
Volker

signature.asc
Description: This is a digitally signed message part.

Re: Invent/gitlab, issues and bugzilla

[Boudewijn Rempt]

On donderdag 4 juli 2019 19:19:17 CEST Nate Graham wrote:
> On 7/4/19 11:06 AM, Christoph Cullmann wrote:
> > Actually, do we really want that every user bug reporter opens an 
> > account on invent.kde.org?
> > 
> > I actually think the split of accounts between phabricator/gitlab vs. 
> > bugzilla is no bad but a good feature.
> 
> It would definitely solve that problem, but there are a few practical 
> problems with this:
> 
> - People would continue to need two accounts (BKO and identity/invent), 

Like I said in my other mail, it's not hugely important for the kind of 
reporter who is not already a developer, and who knows, maybe that can be fixed 
as well. It's not like Identity is universally beloved.

> and the systems wouldn't be integrated as well as thy could be, which 
> negates some of the purported advantages of moving to GitLab in the 
> first place

But that's the _point_. There needs to be a kind of division between user issue 
reporting and developer/development activity.

> - GitLab Issues are lacking some of the features of Phabricator Tasks 
> such as parent & sub-task tracking
> 

Yes, gitlab issues is an all-round aenemic feature, but I could live with it 
for a tasks replacement, but not for a issue reporter replacement.

> - Using GitLab Issues exclusively to replace Phab Tasks will confuse 
> users who are accustomed to using Issues for bug reporting in other 
> projects (though I suppose this could be remedied by renaming "Issues" 
> to "Tasks" in the UI, and implementing a template that explicitly says 
> "Don't use this to report bugs")

And users get would sent to bugs.kde.org anyway; no normal user is going to 
something called "invent.kde.org" to report a bug, unless there's very specific 
guidancce to send them there. 


-- 
https://www.valdyas.org | https://www.krita.org

Re: Invent/gitlab, issues and bugzilla

[Nate Graham]

On 7/4/19 10:39 AM, Boudewijn Rempt wrote:

Is it really true that gitlab makes reporting bugs easier for our users? I.e., 
does it offer easier login, an easier way to add screen shots and screen 
recordings or crash logs?


In my experience, yes. Being able to use a single account for everything 
is a big benefit. And being able to add multiple images and files inline 
via drag-and-drop is a huge improvement over Bugzilla IMO. Then again if 
Bugzilla 6 offers this, that will remove one advantage of GitLab issues.




Is it really true that gitlab makes it easier for our users to make reports of 
a better quality? Like, better wizards, forms, support for smarter templates, 
more ways to cross-check a bug report with other bug reports, or cross-check 
the internal consistency? Is it easier for a user reporting a bug on gitlab to 
tell us which OS, version of OS, version of the application they are using?

Does gitlab offer convenience features for our users like replying by email? (I 
know that some people think email is on the way out, but in real life, everyone 
has email -- and if it were going out -- is there integration with instant 
messaging?) Does gitlab make it easier to be notified of events related to the 
issue?


I'm not sure about these.



We all know that gitlab has a rich text editor. This is modern, but how 
important is that, actually? And how important is it to have a rich text editor 
in our issue reporting system right now? Are we experience a decline in the 
number of user reports because more and more people don't want to use bugzilla?



Anecdotally, yes. I very commonly hear users on social media write and 
say things like "I don't file KDE bugs anymore because Bugzilla is 
ancient and incomprehensible". Though to be fair, they also commonly say 
that it's because we don't do a good enough job triaging bugs, or that 
KDE developers are too mean and abrasive when dealing with users, so 
take it with a grain of salt.



Nate

Re: Invent/gitlab, issues and bugzilla

[Christoph Cullmann]

On 2019-07-04 18:11, Boudewijn Rempt wrote:

On donderdag 4 juli 2019 17:54:23 CEST Nate Graham wrote:

If so, then it seems like the ideal state of affairs would be to 
replace
Bugzilla with GitLab issues as a new bug-reporting front-end for 
users,
and then there would be a separate back-end like what Phabricator 
Tasks

currently offers us that's visible only or mostly to developers, where
the issues can be categorized, organized, and discussed, and
higher-level projects can be coordinated with something. If we can get
something like this, that seems like the ideal outcome to me.


No, exactly the other way around. Bugzilla should stay for users
reporting bugs -- it's the user generated reports that need all the
managing, not the developer tasks. Do we really want to spend time
maintaining scores of labels so we can tag, ourselves, manually, the
platform for a user report and all the other things? Gitlab is just
not suitable for a user-facing issue reporting system. Bugzilla is
better at that, much, much better.


I agree with that.

Bugzilla is nice for user reports, it provides powerful features
to manage a lot of bugs. Some future update will bring all niceties
that ATM only are available on https://bugzilla.mozilla.org.

GitLab issues are nice, too, for e.g. internal developer tasks, like
the Phabricator tasks.

I don't see any issue in keeping this separation that way around.

If teams want to organize/plan their stuff on GitLab with issues, all is 
fine.


But to fragment the user reports over two systems (and it is actually
worse: over bugzilla + XXX projects on gitlab) or to move the user bugs
to some system not that suitable seems weird to me at least.

Actually, out of my experience, the bugs.kde.org UI is the least problem 
we
have, but more the tremendous amount of bugs (even if you discard 
duplicates/invalids)

and the lack of manpower to handle them.

Greetings
Christoph

--
Ignorance is bliss...
https://cullmann.io | https://kate-editor.org

Re: Invent/gitlab, issues and bugzilla

[Nate Graham]

I'm not a fan of "that's just your personal opinion" being used as a 
veiled insult in this thread. Voicing opinions is what we do in a 
discussion. Everybody's opinion is valid.



Here's what we generally seem to agree on:

- bugs.kde.org currently offers a subpar UX for users reporting issues, 
compared to GitHub/GitLab/potentially the future Bugzilla 6 upgrade.


- It's important that user-submitted bugs and developer tools for 
project planning and internal technical discussions be separated from 
one another so users don't interfere in developers' internal 
conversations. We currently have this with Phabricator and Bugzilla 
being separate, and we'd like to not lose some kind of separation.




And it seems like many or most would also agree with the following:

- We should try to unify our infrastructure as much as possible, or else 
the KDE community fragments and working across teams and projects 
becomes harder (e.g. can't move a Bugzilla bug to GitLab, or vice versa).


- Since GitLab is a centralized system that at least aspires to host 
everything "under one roof", if we plan to move to GitLab, it makes the 
most sense to embrace and not maintain separate infrastructure outside 
of it, to the extent that this is practicable.


- What GitLab offers us from a bug triager, developer, reviewer, and 
project manager perspective is inferior to what we currently have 
available in Phabricator and Bugzilla, due to key features being EE-only 
(e.g. Merge request reviews and approvals) or just not available at all 
(e.g. separated infrastructure for user-submitted bugs and developer 
tasks; powerful and granular bug search tools and reports).




Basically our workflow requires that developers interact with users of 
potentially wildly varying levels of technical skill. Those who are more 
skilled should be invited to and allowed to participate in internal 
discussions so that they can actually mature into developers themselves, 
while those who lack technical skills or are personally abusive must be 
kept away from those discussions.


One of the advantages I've seen people mention about GitLab is how they 
are very responsive and open to the possibility of changes. Is there any 
chance we can discuss the above with them to see if there's any way to 
gain more support for our workflows?


If so, then it seems like the ideal state of affairs would be to replace 
Bugzilla with GitLab issues as a new bug-reporting front-end for users, 
and then there would be a separate back-end like what Phabricator Tasks 
currently offers us that's visible only or mostly to developers, where 
the issues can be categorized, organized, and discussed, and 
higher-level projects can be coordinated with something. If we can get 
something like this, that seems like the ideal outcome to me.




Nate

Re: Invent/gitlab, issues and bugzilla

[Boudewijn Rempt]

On donderdag 4 juli 2019 17:54:23 CEST Nate Graham wrote:

> If so, then it seems like the ideal state of affairs would be to replace 
> Bugzilla with GitLab issues as a new bug-reporting front-end for users, 
> and then there would be a separate back-end like what Phabricator Tasks 
> currently offers us that's visible only or mostly to developers, where 
> the issues can be categorized, organized, and discussed, and 
> higher-level projects can be coordinated with something. If we can get 
> something like this, that seems like the ideal outcome to me.

No, exactly the other way around. Bugzilla should stay for users reporting bugs 
-- it's the user generated reports that need all the managing, not the 
developer tasks. Do we really want to spend time maintaining scores of labels 
so we can tag, ourselves, manually, the platform for a user report and all the 
other things? Gitlab is just not suitable for a user-facing issue reporting 
system. Bugzilla is better at that, much, much better.

 
-- 
https://www.valdyas.org | https://www.krita.org

Re: Invent/gitlab, issues and bugzilla

[Sven Brauch]

Hi,

On 7/4/19 5:43 PM, Boudewijn Rempt wrote:
> Sorry, but I don't see any way this is going to end well. KDE
> projects should not use the gitlab issues feature for bug reports.
> Use of the issues feature should be reserved for replacing the
> phabricator tasks functionality. KDE should continue to use
> bugzilla.

I don't currently use the KDE tracker much, but I have to agree Boud and
Christoph here. We currently use the Gitlab tracker at work, for a quite
small project, and it doesn't even really scale to that. I think for a
free-time kind of project one person does with 200 users and 15 issues
reported over 2 years it's fine, but to me that seems to be the use case
it targets.

Two bugtracking systems are also a bad idea; a lot of reports are
assigned to the wrong project, because the user (or any utility) often
cannot know what the correct component is. Also, often one wants to
search for e.g. parts of a trace across projects, or similar things.

Best,
Sven

Re: Invent/gitlab, issues and bugzilla

[Boudewijn Rempt]

On donderdag 4 juli 2019 19:14:30 CEST Ilmari Lauhakangas wrote:
> Nate Graham kirjoitti 4.7.2019 klo 20.02:
> > On 7/4/19 10:39 AM, Boudewijn Rempt wrote:
> >> Is it really true that gitlab makes reporting bugs easier for our 
> >> users? I.e., does it offer easier login, an easier way to add screen 
> >> shots and screen recordings or crash logs?
> > 
> > In my experience, yes. Being able to use a single account for everything 
> > is a big benefit. And being able to add multiple images and files inline 
> > via drag-and-drop is a huge improvement over Bugzilla IMO. Then again if 
> > Bugzilla 6 offers this, that will remove one advantage of GitLab issues.
> 
> Drag'n'drop & multi-upload is planned for BZ 7: 
> https://github.com/bugzilla/bugzilla-ux/wiki/Bugzilla-7-Roadmap
> 
> It would be cool, if entities like KDE e.V. and TDF could team up and 
> sponsor BZ UX improvements so we'd get to BZ 7 & 8 goals faster. I'm not 
> sure about the bureaucracy to make this happen, though.

Heck, I'd add my $1000 to that on my own... For applications with the userbase 
that LibreOffice has, or, a magnitude smaller, but still scary, Krita, a really 
good user issue reporting tool is really important :-)

-- 
https://www.valdyas.org | https://www.krita.org

Re: Invent/gitlab, issues and bugzilla

[Boudewijn Rempt]

On donderdag 4 juli 2019 13:02:24 CEST Kai Uwe Broulik wrote:
> Hi,
> 
>  > What bugzilla has over gitlab issues is reasonable solid set of 
> features that help actually tracking and managing the bug report. It's 
> not that I'm a huge bugzilla fan, it could be much better, but I need 
> those features.
>  >
> 
> I complained about the same thing but I was told you can replicate most 
> of those (OS, platform, etc) using tags/badges and project structures. 
> There isn't a 1:1 mapping of fields and tech we got used to from Bugzilla.
> 

It would mean adding scores of labels to each report. Not exactly easy for the 
reporter, and not easy at all to work with for me as a developer. It's not 
going to be workable.

And that doesn't even take into account that when phabricator gets shelved, 
issues are needed to replace the phabricator tasks. Bug reporting and 
project/task management are not the same thing, after all.

-- 
https://www.krita.org

signature.asc
Description: This is a digitally signed message part.

Re: Invent/gitlab, issues and bugzilla

[Wolthera]

On Thu, Jul 4, 2019 at 1:02 PM Kai Uwe Broulik  wrote:
> I complained about the same thing but I was told you can replicate most
> of those (OS, platform, etc) using tags/badges and project structures.
> There isn't a 1:1 mapping of fields and tech we got used to from Bugzilla.

For gitlab, mutually exclusive tags(which you'd want for things like
OS) are only in the enterprise edition, and adding labels to
bugreports is something that only members of a project can do. I know
that many github projects don't just have triagers but also people who
handle labelling the issues correctly.

For the larger projects, like in my case Krita, I think we would have
to either have a ton of bots to handle the labelling for us, or we
need to give up on attempting to create any order in the tracker(and
again, who will create those bots?). We just get in too many bugs,
there are not enough people to triage all of them, and even if we
would leverage the community here, I am not sure gitlab's permission
system will allow for people who can label but have no desire to have
access to the git repository.

Also keep in mind that we're not done yet with moving to gitlab.
Adding bugzilla migration to the mix might be too much for the
community to handle, so it is probably more efficient to wait for
bugzilla 6 in any case.

I can't really comment much on the different needs of projects where
they have their bugtracker. The thing that keeps returning is that the
larger projects need bugzilla while the smaller projects would benefit
from the easier usability of gitlab issues, which in turn is something
that doesn't necessarily benefit the larger projects, because these
have enough reach to have reached users who have the ability to type
faster than they think and need a bit more encouragement to think
about what they are typing (repellent ux is one of these options. A
non-hostile solution might be possible but to my knowledge no one has
ever programmed an open source version of it).

For what it is worth, there is some minor bugzilla integration already
possible in gitlab [1]. This would allow dual issue style systems
where the bugzilla bugs are the reported bugs and the phabricator
tasks get replaced by the gitlab issues.
[1]: https://invent.kde.org/help/user/project/integrations/bugzilla.md


--
Wolthera

Re: Invent/gitlab, issues and bugzilla

[Luca Beltrame]

Il giorno Thu, 4 Jul 2019 13:31:49 +0200
Wolthera  ha
scritto:

> community to handle, so it is probably more efficient to wait for
> bugzilla 6 in any case.

Speaking of that: does anyone know if there is a roadmap for Bugzilla
6? I'd say the comparison should be done with that as well once it's
out.


pgpqiaJkTzPuK.pgp
Description: Firma digitale OpenPGP

Re: Invent/gitlab, issues and bugzilla

[Christoph Cullmann]

On 2019-07-04 13:35, Luca Beltrame wrote:

Il giorno Thu, 4 Jul 2019 13:31:49 +0200
Wolthera  ha
scritto:


community to handle, so it is probably more efficient to wait for
bugzilla 6 in any case.


Speaking of that: does anyone know if there is a roadmap for Bugzilla
6? I'd say the comparison should be done with that as well once it's
out.


Bugzilla 6 is running late, the latest release plan is somewhen this 
year, see


https://github.com/bugzilla/bugzilla-ux/wiki/Bugzilla-6-Roadmap

But there is activity for this, if you take a look at the work they do 
with

integrating the bugzilla.mozilla.org stuff into that branch.

Greetings
Christoph

--
Ignorance is bliss...
https://cullmann.io | https://kate-editor.org

Re: Invent/gitlab, issues and bugzilla

[Ilmari Lauhakangas]

On 04.07.2019 13:41, Boudewijn Rempt wrote:

So, what gitlab issues have over bugzilla is a rich text editor and a
confidentiality flag. What bugzilla has over gitlab issues is
reasonable solid set of features that help actually tracking and
managing the bug report. It's not that I'm a huge bugzilla fan, it
could be much better, but I need those features.


Bugzilla 6 supports Markdown in comments and automatic inline display of 
attachments such as images and text files (it will skip long text 
files). Note that what will be BZ 6 is live at 
https://bugzilla.mozilla.org/ - the big work during the past couple of 
years has been harmonising Mozilla's custom version and upstream BZ.


Re: confidentiality flag - BZ has supported private reports for a long 
time. Don't ask me how they work as I've never had to set those up.

Also, https://www.bugzilla.org/features/#private
"If you are in the "insider group," you can mark certain attachments and 
comments as private, and then they will be invisible to users who are 
not in the insider group."


Ilmari

Re: Invent/gitlab, issues and bugzilla

[Clemens Toennies]

On 04.07.2019 02:10, Elv1313 . wrote:

So, proposed alternative solution: We make sure that all projects that
want a public-facing bug tracker have a product on bugzilla, and that
they communicate that as the only bug tracker to users for the time being.
Would that work?

Probably not.

1. As Nate points out, the bugzilla UX isn't very friendly to *users*,
but is superior for *maintainers*. The concept of "bug" isn't a thing
to most people. It is a thing only to older software developers and
older users. People have "problems", "issues", "ideas" or "opinions".
*They*, as humans, (hopefully), don't have bugs.

2. As Bhushan points out, it is important for incubation of new
projects. I disagree with Albert on this. "New" developers consider a
well integrated VCS + CI + Issue + Patch (or and pull requests) system
to be the bare minimum of a "good practice" software development
process. Bugzilla+Jenkins+Phab+Git/SVN+Mailing_lists are loosely
integrated. From an Unix point of view, they are different things that
do one thing and do it well. However, from a continuous delivery
pipeline point of view, this is a problem. Tracking a change from its
request (bug report / issue) to its presence on users systems
(store.kde.org / Plasma discover / Neon) and then the feedbacks
(telemetry, drkonqi) should be unified and "bot/tools friendly". With
enough effort, we could find a way to better integrate them. However
"find a way" is currently "complain Ben and wait". I think he has
enough on his shoulder already, so I assume if we never found the
resource to better integrate our components over the year, it wont
magically become a reality tomorrow, or ever. Phab had some
integration, but not much compared to mature (with dev processes)
projects on GitHub or GitLab.

3. This should also not require external tools. As Boudewijn points
out in the "Tipping the apple cart?" thread, new users don't install
Arcanist and it isn't even part of many distributions (or they are
scarred of installing PHP, or they don't know about it). This goes
against the onboarding goals since it makes development experience for
new users inferior to power users by a large margin. Plus, people who
learn software development *now* learn the Agile and GitHub workflow
as the "good practice" and in the same way the older generation learnt
OOP+MVC+SVN or SOA as they "modern way". The worst case is currently
Ubuntu, where, at least recently, it wasn't possible to report a bug
without using Ubuntu (the OS) because the buttons were removed from
Launchpad. So an Ubuntu server or some user "technical friend" could
literally not report problems. This is user and new-developer hostile.
Bugzilla doesn't require external tools per se, but requires to
interact with different systems.

4. Again as Boudewijn points out, a bug tracker is often the wrong
tool. Many users genuinely don't see a difference between
interrogations about how to use a software, a problem with the
software and a review. As the product becomes more popular with the
"general crowd" rather than "geeks", the problem is amplified to the
point Bugzilla becomes a liability.

Given those 4 points, I think it is clear that Bugzilla as an endpoint
for all problems, bugs and project management is clearly an horrible
idea going forward.

* It isn't good for non technical users because well, it isn't for them.
* It isn't good for projects who wish to become part of KDE because
they see this as an outdated workflow lacking tight pipeline
integration.
* It doesn't scale to more popular projects because what they need is
a ticket system in front of the "real" issues to avoid large volume or
non-bug "spam" shadowing the real bugs.
* It doesn't work (well) for potential new contributors who have a
patch for their bug because they need to go though 2 different systems
and they wont.
* It is not bad with bots, but it is definitely harder to integrate
bots with 5 different project rather than 1 with a real API "just for
that".
* DrKonqi not being able to talk to GitLab is a technological issue on
our side that favors bugzilla for legacy reasons. Something like a
Cannonical Apport middleware would help.

GitLab isn't perfect and is too large to be under control. It may die,
sold or go into directions we cannot accept. In 5 years it may be a
problem and blah, blah blah. This was discussed before and a decision
was made. However the idea of rejecting half of what makes GitLab good
in order to unify everything under the Bugzilla umbrella is in my
opinion short signed and classical resistance to changes. Sorry if
this feels a bit harsh.


I agree that switching to gitlab and not planning to use it as suite of 
integrated features is imo pointless.
As Albert mentioned, reducing the need for users and devs to look at and 
maintain multiple interfaces/tools in various places should be one of 
the main reason for deciding to go with gitlab in the first place.
This also goes in line with our goal of attracting fresh new 

Re: Invent/gitlab, issues and bugzilla

[Kevin Ottens]

Hello,

On Thursday, 4 July 2019 10:20:34 CEST Boudewijn Rempt wrote:
> I also think that we should evaluate what those new systems bring us. Has
> webchat.kde.org brought in more new people in comparede to last year? What
> are the positives, what are the negatives now we've used it since February?
> Have the projects that have already moved to Krita seen an increase in
> first patches by newcomers compared to a similar time period last year? We
> should really get those statistics so we know that what we're doing is
> working.

Actually, I plan to have another post of mines on such a topic in the coming 
weeks. I "just" need to manage to resurface.

Regards.
-- 
Kevin Ottens, http://ervin.ipsquad.net


signature.asc
Description: This is a digitally signed message part.

Re: Invent/gitlab, issues and bugzilla

[Boudewijn Rempt]

On donderdag 4 juli 2019 10:07:40 CEST Clemens Toennies wrote:

> I agree that switching to gitlab and not planning to use it as suite of 
> integrated features is imo pointless.
> As Albert mentioned, reducing the need for users and devs to look at and 
> maintain multiple interfaces/tools in various places should be one of 
> the main reason for deciding to go with gitlab in the first place.
> This also goes in line with our goal of attracting fresh new blood (as 
> explained by Emmanuel under point 2. above), be it users who like to 
> participate and can eventually be motivated to try and fix a bug 
> themselves easily after successfully reporting it, or new developers who 
> simply are already familiar with modern interfaces that github or gitlab 
> provide.

As pointed out in other threads in this mail, gitlab actually isn't 
sufficiently like a github clone. The shared workflow is the clone, then merge 
request part. The code review, issue handling and so on is very different, so 
anyone familiar with github will flounder anyway.

> As for a practical move to gitlab, I could see the following work:
> Older projects could be allowed to keep using bugzilla for another 6-12 
> months before adding new bugs there would be disabed (Bugzilla can be 
> kept as legacy read only). If a project wants to switch from bugzilla to 
> gitlab issues right away, it should be allowed to do so and bugzilla 
> disabled then for that project. At the same time every new project 
> should be using gitlab issues default and not even be added to bugzilla 
> retroactively.
>
> That would result in people looking at a project on gitlab first for 
> whatever reason they are interested in including bugs, and only in case 
> that project has no bugs there, check bugzilla. The chances of that 
> workflow happening in this order will be the majority of cases anyway if 
> the plan is to advertise/promote invent.kde.org  
> to users and developers alike as "the new place to go" for projects 
> within KDE.

Keeping the tool users use to report issues and the tool developers use to plan 
and execute their work is a feature, not a problem. I don't want my users to go 
around poking in gitlab. 

> Contrasting that with disabling or limiting gitlab issues and continuing 
> bugzilla will very likely be perceived as odd/weird/disappointing by the 
> majority of people that are going to check out invent.kde.org 
>  and is imo backwards.

On the other hand, we also need to use tools that make our work possible. Me 
being able to do my work, my developers being able to do their work is also 
important. These tools are not for marketing, they are for making the 
development process go better. And not just for newcomers, but also for the 
people actually shouldering the load of triaging ~150 reports a month.

> Plus it adds complexity whereas using gitlab issues could reduce need 
> for maintance, servers, backups, syncing, etc.
> 
> Overall, I think KDE in general should be more active and confident in 
> taking steps to consolidate and modernize its software offerings and 
> technical landscape, especially if adoption of key future infrastructure 
> solutions seems to be happening already in many comparable places (e.g. 
> discourse, as used by mozilla, nextcloud, and all over the place, or 
> gitlab being in use by gnome, debian, purism, manjaro), etc.
> 

I disagree. I'm fine with modernizing bugzilla to bugzilla 6. But gitlab's 
issues feature is not powerful enough to handle the amound of bug reports I 
have to handle. In other words, I cannot do my work with gitlab's issues 
feature. It might look more modern, but it just doesn't have the power. 

I also think that we should evaluate what those new systems bring us. Has 
webchat.kde.org brought in more new people in comparede to last year? What are 
the positives, what are the negatives now we've used it since February? Have 
the projects that have already moved to Krita seen an increase in first patches 
by newcomers compared to a similar time period last year? We should really get 
those statistics so we know that what we're doing is working.


-- 
https://www.krita.org

signature.asc
Description: This is a digitally signed message part.

Re: Invent/gitlab, issues and bugzilla

[Christoph Cullmann]

Hi,


Overall, I think KDE in general should be more active and confident in
taking steps to consolidate and modernize its software offerings and
technical landscape, especially if adoption of key future 
infrastructure
solutions seems to be happening already in many comparable places 
(e.g.

discourse, as used by mozilla, nextcloud, and all over the place, or
gitlab being in use by gnome, debian, purism, manjaro), etc.



I disagree. I'm fine with modernizing bugzilla to bugzilla 6. But
gitlab's issues feature is not powerful enough to handle the amound of
bug reports I have to handle. In other words, I cannot do my work with
gitlab's issues feature. It might look more modern, but it just
doesn't have the power.


I agree with this.

In our company we multiple times reviewed bug trackers (for migrating 
from
Bugzilla), but none actually had a good enough feature set to be 
considered,

beside perhaps Jira (which is non-free/open).

I would wait for the Bugzilla 6 release to judge if the UI arrives in 
the 21th
century before making any decisions what to use. Just that GitLab is 
more

modern doesn't give it all the features one needs.

Greetings
Christoph

--
Ignorance is bliss...
https://cullmann.io | https://kate-editor.org

Re: Invent/gitlab, issues and bugzilla

[Bhushan Shah]

Everyone, let's take a step back.

Original discussion was, if project X can use gitlab issues instead of
bugzilla? If the developers/maintainers prefer?

Potential arguments to which are either,

- No they can't because we forbid it in our manifesto or code of conduct
  or policies
- No they can't because it makes life of other developer harder
- No they can't because it makes life of other user harder

As we stand neither of this arguments apply ... We have no written point
in KDE manifesto which allows community to force a developer tool of
their choice on new or existing project, as long as tool or service is
hosted within KDE infrastructure and doesn't cost sysadmins or community
resources/time maintaining that service. It is important have this
freedom, otherwise next day someone can come up with idea that all
projects should use cmake or autotools or qmake, because all of KDE
community should be using same buildsystem.

- Gitlab is hosted on KDE infrastructure and each KDE contributors can
  access the service using their KDE identity account.
- Gitlab service is/will be actively maintained by KDE sysadmin team and
  using it as bugzilla is not going to cost KDE e.V. any extra money.

If developer/maintainer collectively thinks that using gitlab as bug
tracker makes their life easier instead of depending on bugzilla I don't
understand why other developers would have a problem with that? It's not
making their life difficult at all if they want to contribute, as
mentioned in earlier point Gitlab is accessible to all users and
developers.

As for users, let users decide? I mean we can't speak for all of our
userbase confidently that they love bugzilla and will stop reporting
bugs for other components if certain other project/application starts
using Gitlab for bugtracking, can either of you?

On Wed, Jul 03, 2019 at 08:37:34PM +0200, Boudewijn Rempt wrote:
> Besides, it's already too easy to make a bug report. Getting more bug
> reports is not a priority for me; at this I would prefer to have less
> interaction between developers and users than more, because we're
> going crazy right now.

This is your personal opinion.

> And that's the important thing. Bugzilla is a developer tool, not a
> user tool. We must have easy tools to triage, query, sort, modify sets
> of reports. Bugzilla isn't perfect for that either, but the options
> gitlab gives for handling issues are so limited.

If bugzilla is developer tool, gitlab is also developer tool, let
developer or maintainer decide how to best use it.

On Thu, Jul 04, 2019 at 10:20:34AM +0200, Boudewijn Rempt wrote:
> On the other hand, we also need to use tools that make our work
> possible. Me being able to do my work, my developers being able to do
> their work is also important. These tools are not for marketing, they
> are for making the development process go better. And not just for
> newcomers, but also for the people actually shouldering the load of
> triaging ~150 reports a month.

If Kaidan, Calindori or Plasma Mobile uses the Gitlab for issue reporting
because of either a) choice of maintainer or b) choice of specific
sub-community, that decision doesn't affect krita, okular or other KDE
applications.

> I disagree. I'm fine with modernizing bugzilla to bugzilla 6. But
> gitlab's issues feature is not powerful enough to handle the amound of
> bug reports I have to handle. In other words, I cannot do my work with
> gitlab's issues feature. It might look more modern, but it just
> doesn't have the power. 

This is your personal opinion.

On Thu, Jul 04, 2019 at 10:39:15AM +0200, Christoph Cullmann wrote:
> In our company we multiple times reviewed bug trackers (for migrating
> from Bugzilla), but none actually had a good enough feature set to be
> considered, beside perhaps Jira (which is non-free/open).
> 
> I would wait for the Bugzilla 6 release to judge if the UI arrives in
> the 21th century before making any decisions what to use. Just that
> GitLab is more modern doesn't give it all the features one needs.

This is your personal opinion.

In general, I respect everyone's personal opinion that bugzilla at
moment superior to the gitlab issues, but at same time I also want to
respect other developers opinion/choices as long as they abide by the
KDE manifesto written and supported by our community.

Thanks


-- 
Bhushan Shah
http://blog.bshah.in
IRC Nick : bshah on Freenode
GPG key fingerprint : 0AAC 775B B643 7A8D 9AF7 A3AC FE07 8411 7FBC E11D


signature.asc
Description: PGP signature

Re: Invent/gitlab, issues and bugzilla

[Luigi Toscano]

Bhushan Shah ha scritto:
> Everyone, let's take a step back.
> 
> Original discussion was, if project X can use gitlab issues instead of
> bugzilla? If the developers/maintainers prefer?
> 
> Potential arguments to which are either,
> 
> - No they can't because we forbid it in our manifesto or code of conduct
>   or policies
> - No they can't because it makes life of other developer harder
> - No they can't because it makes life of other user harder
> 
> As we stand neither of this arguments apply ... We have no written point
> in KDE manifesto which allows community to force a developer tool of
> their choice on new or existing project, as long as tool or service is
> hosted within KDE infrastructure and doesn't cost sysadmins or community
> resources/time maintaining that service. It is important have this
> freedom, otherwise next day someone can come up with idea that all
> projects should use cmake or autotools or qmake, because all of KDE
> community should be using same buildsystem.

Sorry, but We did exactly this. We all switched to git for code. We all
de-facto switched to CMake for Qt-based projects, whenever is possible. And
there are good reasons for that.

> 
> - Gitlab is hosted on KDE infrastructure and each KDE contributors can
>   access the service using their KDE identity account.
> - Gitlab service is/will be actively maintained by KDE sysadmin team and
>   using it as bugzilla is not going to cost KDE e.V. any extra money.
> 
> If developer/maintainer collectively thinks that using gitlab as bug
> tracker makes their life easier instead of depending on bugzilla I don't
> understand why other developers would have a problem with that? It's not
> making their life difficult at all if they want to contribute, as
> mentioned in earlier point Gitlab is accessible to all users and
> developers.

It is important for the rest of the community, as I mentioned earlier (see:
consistency, and tooling). That's it.

> As for users, let users decide? I mean we can't speak for all of our
> userbase confidently that they love bugzilla and will stop reporting
> bugs for other components if certain other project/application starts
> using Gitlab for bugtracking, can either of you?

Users don't decide where to report bugs: they follow the instructions (I can
report countless of request of "where can I report this").
Having two places makes things confusing.


> 
> On Wed, Jul 03, 2019 at 08:37:34PM +0200, Boudewijn Rempt wrote:
>> Besides, it's already too easy to make a bug report. Getting more bug
>> reports is not a priority for me; at this I would prefer to have less
>> interaction between developers and users than more, because we're
>> going crazy right now.
> 
> This is your personal opinion.
> 
>> And that's the important thing. Bugzilla is a developer tool, not a
>> user tool. We must have easy tools to triage, query, sort, modify sets
>> of reports. Bugzilla isn't perfect for that either, but the options
>> gitlab gives for handling issues are so limited.
> 
> If bugzilla is developer tool, gitlab is also developer tool, let
> developer or maintainer decide how to best use it.
> 
> On Thu, Jul 04, 2019 at 10:20:34AM +0200, Boudewijn Rempt wrote:
>> On the other hand, we also need to use tools that make our work
>> possible. Me being able to do my work, my developers being able to do
>> their work is also important. These tools are not for marketing, they
>> are for making the development process go better. And not just for
>> newcomers, but also for the people actually shouldering the load of
>> triaging ~150 reports a month.
> 
> If Kaidan, Calindori or Plasma Mobile uses the Gitlab for issue reporting
> because of either a) choice of maintainer or b) choice of specific
> sub-community, that decision doesn't affect krita, okular or other KDE
> applications.

It does, as a global community.

> 
>> I disagree. I'm fine with modernizing bugzilla to bugzilla 6. But
>> gitlab's issues feature is not powerful enough to handle the amound of
>> bug reports I have to handle. In other words, I cannot do my work with
>> gitlab's issues feature. It might look more modern, but it just
>> doesn't have the power. 
> 
> This is your personal opinion.

Just like yours.



> 
> On Thu, Jul 04, 2019 at 10:39:15AM +0200, Christoph Cullmann wrote:
>> In our company we multiple times reviewed bug trackers (for migrating
>> from Bugzilla), but none actually had a good enough feature set to be
>> considered, beside perhaps Jira (which is non-free/open).
>>
>> I would wait for the Bugzilla 6 release to judge if the UI arrives in
>> the 21th century before making any decisions what to use. Just that
>> GitLab is more modern doesn't give it all the features one needs.
> 
> This is your personal opinion.

Do you mean that you don't want to evaluate the tools? Interesting.

> 
> In general, I respect everyone's personal opinion that bugzilla at
> moment superior to the gitlab issues, but at same time I also want to
> 

Re: Invent/gitlab, issues and bugzilla

[Boudewijn Rempt]

Is it just me, or is the quoting in this mail a bit crazy? In any case, I'm 
fine with projects deciding to use gitlab for their bugtracker. I think they 
would be crazy to do so, since gitlab's issues system lacks just about 
everything needed to categorize, prioritize, search and update bugs. (Note "I 
think... -- that's a opinion, "lacks just about everything" -- that is a fact.)

On donderdag 4 juli 2019 11:49:15 CEST Bhushan Shah wrote:

> 
> On Wed, Jul 03, 2019 at 08:37:34PM +0200, Boudewijn Rempt wrote:
> > Besides, it's already too easy to make a bug report. Getting more bug
> > reports is not a priority for me; at this I would prefer to have less
> > interaction between developers and users than more, because we're
> > going crazy right now.
> 
> This is your personal opinion.

No, this is not a personal opinion. It is not even an opinion. This is the 
experience of the maintainer of the KDE product that gets most bug reports per 
week. It is a fact you need to take into consideration.

> 
> > And that's the important thing. Bugzilla is a developer tool, not a
> > user tool. We must have easy tools to triage, query, sort, modify sets
> > of reports. Bugzilla isn't perfect for that either, but the options
> > gitlab gives for handling issues are so limited.
> 
> If bugzilla is developer tool, gitlab is also developer tool, let
> developer or maintainer decide how to best use it.

Except that for tracking bug reports it is an _inferior_ tool because it lacks 
the abilities needed to work with large numbers of reports for complex 
applications. It doesn't even have components -- as far as I can tell, 
everything needs to do be done with just one thing: labels. 

> On Thu, Jul 04, 2019 at 10:20:34AM +0200, Boudewijn Rempt wrote:
> > On the other hand, we also need to use tools that make our work
> > possible. Me being able to do my work, my developers being able to do
> > their work is also important. These tools are not for marketing, they
> > are for making the development process go better. And not just for
> > newcomers, but also for the people actually shouldering the load of
> > triaging ~150 reports a month.
> 
> If Kaidan, Calindori or Plasma Mobile uses the Gitlab for issue reporting
> because of either a) choice of maintainer or b) choice of specific
> sub-community, that decision doesn't affect krita, okular or other KDE
> applications.

Except that people _are_ talking about bugzilla as if it's yesterday's 
technology because it's too old fashioned and needs to go away.

> 
> > I disagree. I'm fine with modernizing bugzilla to bugzilla 6. But
> > gitlab's issues feature is not powerful enough to handle the amount of
> > bug reports I have to handle. In other words, I cannot do my work with
> > gitlab's issues feature. It might look more modern, but it just
> > doesn't have the power. 
> 
> This is your personal opinion.

No, this is not an opinion. It is my experience: it is a fact. I need a capable 
tool.

> 
> On Thu, Jul 04, 2019 at 10:39:15AM +0200, Christoph Cullmann wrote:
> > In our company we multiple times reviewed bug trackers (for migrating
> > from Bugzilla), but none actually had a good enough feature set to be
> > considered, beside perhaps Jira (which is non-free/open).
> > 
> > I would wait for the Bugzilla 6 release to judge if the UI arrives in
> > the 21th century before making any decisions what to use. Just that
> > GitLab is more modern doesn't give it all the features one needs.
> 
> This is your personal opinion.

That also is not an opinion. Comparing features of gitlab issues and bugzilla 
shows that gitlab issues lacks features. That makes it a fact.

> In general, I respect everyone's personal opinion that bugzilla at
> moment superior to the gitlab issues, but at same time I also want to
> respect other developers opinion/choices as long as they abide by the
> KDE manifesto written and supported by our community.

Pretty much everything which you did away with as "personal opinion" is nothing 
of the sort.

Like I said above, I'd be fine with projects using gitlab for their issue 
tracking. I don't think that is will be a big problem for users to go gitlab 
for one project and to bugzilla for another project.

But for a project like Krita, gitlab issues is not suitable because it is 
lacking in features. And that's a fact. Not an opinion.


-- 
https://www.krita.org

signature.asc
Description: This is a digitally signed message part.

Re: Invent/gitlab, issues and bugzilla

[Christoph Cullmann]

On 2019-07-04 12:08, Luca Beltrame wrote:

It does, see above why. As a downstream I don't want to chase the
projects to see which platform they use for reporting bugs. And yes, I
have direct experience professionally with another, unrelated FOSS
project (Bioconductor) which doesn't have a "central" bug reporting
infrastructure and leaves to the maintainers how to get their reports:
it's an absolute hell to wade through.

I don't want to see this in KDE.


Me neither.

This would make a lot of things harder.

e.g. how to be able to easily move bugs between products on gitlab and
bugzilla? At the moment it is very easy to move bugs application got
reported to e.g. the right framework. If we have more than one 
infrastructure

for bug reports this will no longer be that easy.

Greetings
Christoph

--
Ignorance is bliss...
https://cullmann.io | https://kate-editor.org

Re: Invent/gitlab, issues and bugzilla

[Kai Uwe Broulik]

Hi,

> What bugzilla has over gitlab issues is reasonable solid set of 
features that help actually tracking and managing the bug report. It's 
not that I'm a huge bugzilla fan, it could be much better, but I need 
those features.

>

I complained about the same thing but I was told you can replicate most 
of those (OS, platform, etc) using tags/badges and project structures. 
There isn't a 1:1 mapping of fields and tech we got used to from Bugzilla.


Cheers
Kai Uwe

Re: Invent/gitlab, issues and bugzilla

[Luca Beltrame]

Il giorno Thu, 4 Jul 2019 15:19:15 +0530
Bhushan Shah  ha scritto:

> - No they can't because it makes life of other developer harder
> - No they can't because it makes life of other user harder

- No they can't because it creates inconsistencies and makes some
  user-facing tools like drkonqi useless with people that don't use
  Bugzilla.
- No they can't because then it's going to get hard for both users
  *and* downstreams to find *where* they report their issues given that
  project X may use Bugzilla and Y might use GitLab

> If developer/maintainer collectively thinks that using gitlab as bug
> tracker makes their life easier instead of depending on bugzilla I

And what about making existing tools useless? No, the fact that project
X doesn't use them is not an excuse. It may be valid *at this point in
time* only.

> specific sub-community, that decision doesn't affect krita, okular or
> other KDE applications.

It does, see above why. As a downstream I don't want to chase the
projects to see which platform they use for reporting bugs. And yes, I
have direct experience professionally with another, unrelated FOSS
project (Bioconductor) which doesn't have a "central" bug reporting
infrastructure and leaves to the maintainers how to get their reports:
it's an absolute hell to wade through.

I don't want to see this in KDE.

> In general, I respect everyone's personal opinion that bugzilla at
> moment superior to the gitlab issues, but at same time I also want to
> respect other developers opinion/choices as long as they abide by the

I see nothing that allows an informed decision. Why is not Bugzilla
acceptable? Why is GL better? No, familiarity and onboarding reasons
are not enough. Please at least try to outline first the advantages and
disadvantages of both.



pgpGwwb931XRA.pgp
Description: Firma digitale OpenPGP

Re: Invent/gitlab, issues and bugzilla

[Boudewijn Rempt]

On donderdag 4 juli 2019 12:08:00 CEST Luca Beltrame wrote:

> I see nothing that allows an informed decision. Why is not Bugzilla
> acceptable? Why is GL better? No, familiarity and onboarding reasons
> are not enough. Please at least try to outline first the advantages and
> disadvantages of both.

Let's see whether we can do an initial feature comparison:

 gitlab   bugzilla
rich text editor with embedded images  X -
Attachments for large files- X
keywords or labels X X
moving issues between product  X X
status workflow open/closed   
reported/confirmed/assigned/resolved/closed
version of product - X
component  - X
OS/Platform- X
OS/Platform version- -
mark as duplicate  - X
target milestone   X X
depends on/blocks  - X
confidentiality flag   X -
reports (like weekly)  - X
integration with commit workflow   X X
integration with merge requestsX X
advanced search- X
duplicates - X

So, what gitlab issues have over bugzilla is a rich text editor and a 
confidentiality flag. What bugzilla has over gitlab issues is reasonable solid 
set of features that help actually tracking and managing the bug report. It's 
not that I'm a huge bugzilla fan, it could be much better, but I need those 
features.

The reason for that is that gitlab's issues feature seems to have been designed 
for the way smaller, internal teams work inside a company, where they would 
create their own issues during development, or create issues for tasks they 
receive from their product owners. It's not designed for receiving thousands of 
end-user reports a year. It's not designed to be the public face of a project.

-- 
https://www.krita.org

signature.asc
Description: This is a digitally signed message part.