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 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 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 <http://invent.kde.org> 
to users and developers alike as "the new place to go" for projects 
within KDE.

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 
<http://invent.kde.org> and is imo backwards.
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.

Greetings, Clemens.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-community/attachments/20190704/d81d8d1f/attachment.htm>