Re: Choice of bug tracker

[Dmitry Gutov]

On 29/08/2023 18:06, Stefan Kangas wrote:
> 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.

Very good.

> >    - 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.

The fact that LibreJS complains doesn't mean that the software is 
non-free. It just means that the annotations that LibreJS would 
recognize are missing. Most of the Internet is missing those. The 
overall mission of having JS files come with licenses in some form or 
other doesn't sound bad, but it shouldn't be a hard requirement for our 
platform, I think. It's not an urgent thing to fix.

(OTOH, for the main endeavor of finding the new common Forge software 
for all GNU projects it does seem pretty valuable, if only for political 
reasons.)

> > 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.

Very good.

We have an existing Gitlab instance which should work at the testing 
ground. It's probably better to ask the admins to upgrade it to the 
latest version first, or if it was not their job, get in touch the 
people previously responsible for it.

And then we should ask some more folks to start working with it and come 
back with *prioritized* list of current problems.

> > 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.

Probably, yes. Though I'm less sure about that regarding Sourcehut, 
personally. It's new and fairly novel, but familiarity (for the general 
crowd) is not high on its list of priorities.

> 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.

Bugzilla is indeed the fallback option from my POV. But the other danger 
is that we spend the next 10+ years never agreeing on anything and not 
moving at all; Bugzilla is definitely better than *that* outcome.