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