bug-lilypond
[Top][All Lists]
Advanced

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

Re: What is the point of bug-lilypond?


From: David Kastrup
Subject: Re: What is the point of bug-lilypond?
Date: Sat, 16 Oct 2021 13:09:11 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux)

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
b) read up on the categories and flags we use for bug reports
c) triage their bug and determine the proper categories and severity
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.

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.

Something like bug-guile@gnu.org immediately gates into a debbug
tracker: that's sort of punting on having a bug reporting list (and the
documentation does not really mention the list I think) but at least
gets stuff into the system (where it sometimes is left to rot without
further feedback).

That's still preferable to what you propose, but quite worse than having
an actual bug reporting list like we have now.

-- 
David Kastrup



reply via email to

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