[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: What is the point of bug-lilypond?

From: Jean Abou Samra
Subject: Re: What is the point of bug-lilypond?
Date: Sat, 16 Oct 2021 13:57:43 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.1.2

Le 16/10/2021 à 13:09, David Kastrup a écrit :
Jean Abou Samra <jean@abou-samra.fr> writes:
Hi James, Werner, all,
I would say that 'most' emails to the bug list do NOT need an issue, they are either replies to emails or pointers to existing Issues that explain bug or technical discussions about why something is not a bug but a limitation of what is possible based on how we code things (which itself engenders more emails).
Yes, absolutely -- and you're doing this very well. However, when you decide that the report calls for an issue, do you edit it (change example, use different terms) or is it good enough to be pasted as-is? I may be wrong, and I certainly do not want to diminish your work on bug reports, but I had the impression that most often the issue was made just from the email thread. That's also what I usually do. To be clear, I am not proposing that we change anything to the way we respond to bug reports (discussing whether it's a bug, pointing to documentation, etc.) which is handled very well as it is. It just appears to me that the bug-lilypond mailing list is redundant as the same tasks can be done better via the issue tracker.
I disagree. "can be done better via the issue tracker" glosses over who does the stuff. Having a mailing list to report bugs gives us a low barrier to receive user feedback regarding problems, perceived and genuine. Leaving only the tracker requires anybody encountering a problem to a) register an account on GitLab

Well, compare this to subscribing to the list
and receiving others' bug reports afterwards.

b) read up on the categories and flags we use for bug reports

Again, I was _not_ proposing to ask users to do that
at all. To report a problem, open an issue and that's
all. Just like "send an email and that's all".

Adding labels is the role of the same people who
triage bug-lilypond now.

c) triage their bug and determine the proper categories and severity

Similarly, no.

d) enter their bug into GitLab and deal with responses That's basically giving the message "non-programmers and casual users: don't even bother". For a programming library, that may be sort of a reasonable tradeoff. For an application intended for musicians, I don't see that.

For the reasons above, I don't think so.

There may be a generational effect in views on the
ease of working with mailing lists. I can at least
see a lot of software not primarily intended for
programmers directing bug reports to a web system
directly. Examples: Firefox, WikiMedia, GIMP (GNU
software), LibreOffice, MuseScore, Frescobaldi.

Additionally having a bug-xxx@gnu.org mailing list for receiving bug reports is standard for GNU applications, so even for some important subset of programmers it is the expectation that this should be a way to enter problem reports.

What the guidelines say about it is

  Once a program is in use, you will get bug
  reports for it. Most GNU programs have their
  own special lists for sending bug reports.
  The advertised bug-reporting email address
  should always be ‘bug-package@gnu.org’, to
  help show users that the program is a GNU package,
  but it is ok to set up that list to forward
  to another site if you prefer.

  We also have a catch-all list,
bug-gnu-utils@gnu.org, which is used for all
  GNU programs that don’t have their own specific
  lists. But nowadays we want to give each program
  its own bug-reporting list and move away from
  using bug-gnu-utils.

“Most GNU programs” does not suggest that this
is a requirement. If it is a concern nevertheless,
the bug-lilypond address can be made to redirect to
a GitLab address that opens issues (every GitLab
user can have one per project; this one could
be LilyPond Bot's).


reply via email to

[Prev in Thread] Current Thread [Next in Thread]