Re: Choice of bug tracker

[Dmitry Gutov <dmitry@gutov.dev>]

On 31/08/2023 23:44, Stefan Kangas wrote:
> Ihor Radchenko<yantar92@posteo.net>  writes:
> 
>>> It isn't trivial when people respond to several threads in the same
>>> message.  You can see examples of this on this list, just look at the
>>> recent large threads.
>> I can see how that is a problem. So, is it a +1 for "modern trackers"
>> and -1 for "mailing lists"?
> Perhaps, yes.  I'd definitely be much happier if we had a bug tracker
> that made it possible to split threads after the fact.  If that's
> something you can do with a "modern tracker", then it would certainly
> help.
> 
> We are more disciplined these days, but I have seen many old,
> sprawling bug threads with dozens upon dozens of replies, more than
> half of which are about something else entirely.  Coming back to such
> threads after N years, as I've often done, it does take a long time to
> find some signal in there: to figure out what is fixed, what is not,
> what is a separate issue, and so on.

That would be nice to be able to do, but is that feasible?

If the main interface for interacting with discussions for many people 
remains their mail client, whatever we try to split after the fact (BTW, 
I know of such features in "forum software" similar to Discourse, but 
probably not in Gitlab's issues) wouldn't be reflected in everybody's 
existing mail archives.

This would only work if we/they used an Emacs client that worked off 
Gitlab's programmatic API instead, showing the most recent views. But 
that would take a fair amount of work to create, and wouldn't support 
the existing mail rules/filters/etc, at the very least.

A "modern tracker" could encourage us to use more structured threads 
going forward, though.