Bug report: Take bug reporting off the mailing list

[Norman Gray]

Nicola, hello.

On 9 Feb 2024, at 19:37, Nicola Talbot via tex-live wrote:

> Rather than spending time making a list that can easily go out of date, why not just direct users to the package page on CTAN? There may be a "Home page", "Bug tracker" or "Repository" link on the package page or contact details in the README or at the start of the documentation. That's the most up-to-date information that's publicly available. If that information isn't there, then there's no support.

That's true, and I make a point of keeping that sort of information, including repo links, up to date for 'my' CTAN entries, but I don't in practice get many (any?) bug-reports created that way, in part because doing so would require a user creating an account on the forge I use.  That's not a _massive_ hurdle, but it's still a road-bump.

I've just taken a look at a randomish dozen of the packages in [1].  All the ones I looked at had a maintainer listed, but only a couple of them had forges associated with them [2], and only one of those was at github (where a user _might_ have an account already).

The reason I suggested that such a bug-report hub might be 'on or near TeXLive' is that it might be legitimate to share the contact details of maintainers from CTAN to the putative TeXLive bugparade (but not of course to make them public; and a GDPR bulb immediately illuminates, of course, but the relevant permissions might be included in a necessary opt-in on the part of a package maintainer).  Maintainers typically confirm or update those contact details whenever they update a package, so they're a source of truth.

If a package does have a forge, then I've no doubt it would be _feasible_ for the TL bugparade to do some clever integrations, creating tickets, but that wouldn't be necessary, because an absolutely minimal service would still provide value.

  1. A package user discovers a possible/probably bug in package X, so...
  2. TLmgr (for example) prompts for details and logs a report at the TL forge, which...
  3. looks up and sends an email to the maintainer, before...
  4. telling the user 'the package maintainer has been told -- thanks for shouting into the void!'.
  5. If the package maintainer decides to fix this, they can note that in the TL forge, which...
  6. lets the user know that a fix will appear at some future point when the package is next released.

This also means that

  7. Another package user stumbles across the same bug, and...
  8. learns from the TL forge that it's already in hand, possibly examining any comments on the report.

Effort: There are a few well-known bugtrackers.  A pretty standard install of one of those, with minimal integration with CTAN, might be 'job done' with only very modest ongoing maintenance demands.  I suspect there'd be more work/thought required in deliberating about the language on the front page (friendly, but no commitments), than in the install.  That's maybe a student/intern summer project?

[There are lots of 'mights' and 'maybes' here, of course!]

Best wishes,

Norman


[1] https://www.ctan.org/tex-archive/macros/latex/contrib
[2] by chance, once of the packages was one of yours, Nicola!

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