Re: Choice of bug tracker

[Stefan Kangas]

Dmitry Gutov <dmitry@gutov.dev> writes:

> Last time we produced this overblown list which mixed necessities with
> nice-to-haves: https://gitlab.com/gitlab-org/gitlab/-/issues/28152

Hmm, some of the ideas on there seem very ambitious, indeed.  I'd
propose forgetting about the wishlist type items and focusing hard on
what really matters.  The list Eli just posted seems like the best
starting point.

>   - ReCaptcha replacement (actually seems fixed now:
> https://gitlab.com/gitlab-org/gitlab-foss/-/issues/46548#note_203922493)
>   - LibreJS (we already know the JS files have satisfactory licenses;
> there was a fair amount of discussion around the assets pipeline, but no
> resolution: https://gitlab.com/gitlab-org/gitlab/-/issues/15196)

We can't rely on non-free software, so these would need to be fixed.
At least for the GNU/Emacs instance, but even better in the Gitlab
upstream.

> There were also a few functional things like inability to include diffs
> in Merge Request notifications which seems like a genuine omission, that
> seems easy to sell to gitlabbers, and I wouldn't mind looking into.

Sounds great!

> Regarding "workability", we have EMBA for people to try out. It's been
> there for several years. Unless Gitlab is crossed out from the list of
> contestants already.

AFAIU, we did not cross out Gitlab.  It is a candidate, provided that
we can fix any outstanding issues, and make it fit existing workflows
well enough.

> I suppose [Bugzilla] was not in the list of "forges" because it only provides
> bug tracking. If we don't manage to switch to Gitlab or SourceHut, we
> can try using Bugzilla, at least. I'm not loving its "new bug" and the
> nonexistent "most recent issues/activity" pages, but it would still be
> an improvement.

Something like Gitlab or Sourcehut would be more capable, yes.  I also
believe they are closer to what we need if we are looking to make it
easier to recruit new developers.

The risk with spending time on Bugzilla is that we would end up using
that for the next 10+ years, when a bit (a lot?) more work could have
moved us to something like Sourcehut or Gitlab instead.  So
personally, I'd rather see that we focused on more featureful options.
But that's me.

> 2) Other bug trackers/forges which have any kind of web API can be
> adapted in a similar fashion: running a script when an email is received
> is easier than implementing a new feature in Gitlab, with
> UI/settings/permissions, so if we find that Gitlab is otherwise okay but
> its capability to modify issues over email is lacking, I can volunteer
> to look into this too.

That sounds workable.