Invent/gitlab, issues and bugzilla

[Elv1313 .]

> 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 we need to discuss this here and now rather than as a
separate discussion "in the future".

On Wed, 3 Jul 2019 at 16:46, Thomas Pfeiffer <thomas.pfeiffer at kde.org> wrote:
>
> On 7/3/19 9:05 PM, Luigi Toscano wrote:
> > Boudewijn Rempt ha scritto:
> >> On woensdag 3 juli 2019 20:23:41 CEST Nate Graham wrote:
> >>> 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.
> >>
> >> But are they the same things? I need both user reports and developer tasks/projects. The only task-like system github offers is the issues system, isn't it?
> >
> > Yes, but my point is that gitlab issues have been used also for bugs so far.
>
> It seems like we all agree on the problem (different KDE projects using
> different tools for bug reporting by users), but not on your proposed
> solution (disabling issues in GitLab completely) since that would affect
> our use of GitLab Issues for internal issue / task tracking.
>
> 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.
>
> Then we can still use GitLab Issues for internal purposes.
>
> And evaluating whether we want to switch over to GitLab Issues for
> public-facing bug tracking eventually would be an independent discussion.
>
> Would that work?
>
> Cheers,
> Thomas