Bug report: Take bug reporting off the mailing list

[Zdenek Wagner]

pá 9. 2. 2024 v 17:41 odesílatel Norman Gray <gray at nxg.name> napsal:
>
>
> Greetings,
>
> [the following is a bit waffly, because it may be a daft idea]
>
> On 9 Feb 2024, at 16:02, Jonathan Fine wrote:
>
> > I think it would be helpful if we could find ways to help direct users to a
> > better place for reporting or getting help with the issue they have, as a
> > result of using the software that texlive has installed on their computer.
>
> I get a trickle of bug-reports for the couple of packages I maintain, but they emerge by virtue of me following the corresponding tags on StackExchange, or less often by people emailing me directly.  I don't _think_ any has come via an issue tracker on a forge (apart from anything else, I've moved the main repository around a bit).
>
> > Perhaps for some of the misplaced issues that come in, we could make an
> > effort to understand why the user chose to send the issue here rather than
> > some other better place. This would help give us here more of a shared
> > understanding of the problem.
>
> Of the people who'd notice a package bug, and feel motivated to report it, I wonder what fraction are folk who'd naturally gravitate towards an issue list on the package's source repository.  I think that fraction might well be lower than for other 'software', and for that reason I suspect that a forge-local issues list is _not_ the obvious best destination to recommend, that it would be for other software.
>
> I suspect that the tex-live at tug.org list gets bug reports because, as Norbert points out, it's the nearest thing to an obvious destination for such a report, and yes, there's probably a lot of contradictory history in what people think of as an obvious way to use, or participate in, or (not) subscribe to, a mailing list.
>
> Perhaps it _would_ make sense to have some sort of issues list, supported on or near TeXLive, which can act as a central point for bug reports?  It's unconventional for such an issues list to be disconnected from a source repository, but -- as I say -- the user base may be different from other software users.
>
> As Jonathan suggests, the texlive software could potentially direct people towards this, even helping them template a good bug report.
>
> Norbert wrote:
>
> > Think about an arbitrary package in TeX Live, and ask
> > yourself, how can I contact the author. This is very hard since many
> > packages are one-person developments without any regular bug tracker or
> > issue access point.
> >
> > But we as TeX Live maintainers cannot take over this part, since this
> > would burn us out in very short time.
>
> It would be cute if that tracker could be integrated with other repositories, or with the TeXLive process, but not necessary.  It probably needn't do more than curate a webpage, and ping the package author, if they've opted in to the service (and there will be email addresses obtainable from CTAN).  If it were clear that this was simply a clearing house ('the package author will be informed') and not the TeXLive project taking on any responsibility, that would still be useful.  Making that 'no responsibility' clear would be necessary, for the reasons Norbert mentions.
>
> How would I feel about that, as a package author?  I think pretty relaxed, and yes, I'd probably sign up to get pinged on reports on my packages.
>
> This would of course be a bit of a project to set up, but it might be that something _very_ basic could be set up relatively straightforwardly, have minimal ongoing maintenance obligations, and make a big difference.
>
As a package author I have my e-mail address in the documentation so
that people can contact me. I will hesitate to be subscribed to a feed
for all existing packages because it might overwhelm me and especially
after returning from vacations I will have a lot of irrelevant mails.
On the other hand, people knowing the contact to the package manager
will not right to a generic list.

There is another problem which has already been mentioned. User may
not be able to recognize the source of the problem. Maybe I am now a
bit off topic but take it as an example. I have reported a bug in a
Linux package. The package works fine after fresh install in Fedora by
"dnf install". It always works after each "dnf upgrade" but does not
work after "dnf system-update". It is fixed automatically with "dnf
upgrade" when a new kernel is available. I managed to find that the
kernel modules are copied to the computer but not properly configured
which can be fixed manually. I described everythnig in the bug report
but probably the package maintainers are not responsible for package
updates. Thus the final status of my bug report is "won't fix" and I
do not know whom to contact. Here, in TeX Live, somebody always knows
whom to contact and helps to solve the issue.

> Best wishes,
>
> Norman
>

Zdeněk Wagner
https://www.zdenek-wagner.eu/



>
> --
> Norman Gray  :  https://nxg.me.uk
>