[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 15:49:46 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.1.2

Le 16/10/2021 à 14:28, David Kastrup a écrit
bug-lilypond@gnu.org is not a subscribers-only list and it is expected
that responses include a Cc: to the sender.

Ah, ok. I had inferred the contrary from

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".
And ignore all the bits and pieces shown in the bug tracker?  Basically
force people to use a complex tool and give them the option of either
appearing incompetent by not actually using the tool as intended or
investing a lot of additional time for figuring out things?

Adding labels is the role of the same people who
triage bug-lilypond now.
Doesn't sound like you are saving those "same people" a lot of work
while adding it (or the impression) to those reporting it.

c) triage their bug and determine the proper categories and severity
Similarly, no.
And how are they to figure this out?  Particularly when they see how
other people are cleaning up their issue and changing it around?

By reading an updated version of the guidelines at

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.
I think your model of what a "user" should be thinking, doing, and
feeling might be assuming too much.  There is a reason we arrived at
such a low-barrier method of doing things.  We already were working with
web-interface based bug trackers when we designed our current processes
and the discussions are not new.  Lowering the barrier of participation
for an application primarily addressing the needs of musicians rather
than programmers was a real issue already while Graham had been leading
the project.  I don't think that the principal problems have changed,

Personally, I know that I myself (and I am not really a non-programmer)
tend to think twice about reporting problems to applications that
require me to sign up to some tracker or whatnot before accepting my
feedback.  I won't enter into that kind of commitment for something
unless really necessary.

Le 16/10/2021 à 14:18, Jonas Hahnfeld a écrit :
Am Samstag, dem 16.10.2021 um 12:55 +0200 schrieb Jean Abou Samra:
We're all volunteers and nobody is entitled
to respond to bug reports. So if one slips
through the cracks occasionally, I believe
it's better to have it in the database and
keep it for future developers walking around
there than let it be forgotten about. (I do
walk around a lot in the tracker, including
10-year-old issues, and sometimes they give
nice ideas. \vshape was born like that.)
In my opinion, this is a very weak argument: The archives of bug-
lilypond go back more than 20 years (first month is 2001-07). This is
longer than any bug tracker was used (Google Code, SourceForge) and I
would bet it is longer than GitLab will be used.

Is anybody actually reading these archives though?
I don't. I would if they supported filtering out
all the bugs that have been fixed in the meantime.

Ignoring a report is my opinion the worst of all outcomes since
it not only loses information but discourages people to engage
in later reports or further investigation.
Nothing is lost. Also I am not so sure it does discourage engagement
that much, if a bug is that big a deal and we miss it, then I am sure
that another person would report it, again we've plenty to do as it is.
I was talking about engagement from the user reporting
the bug.
Honest question: Do you really expect this to change if issues are
opened on GitLab instead of sent to a mailing list? If it's a good
report but nobody starts to work on it immediately, there won't be a
response on GitLab either. Right now, there's at least the
acknowledgement that it is considered a bug and an issue was opened.

Take the bug report:


Ignored on guile-user, ignored on guile-devel.
So I finally sent it to bug-guile, where nobody
reacted either. I feel safer having dumped it
on the Guile bug tracker (through bug-guile) because
when in 2 years (let's hope...) Guile gets
developers who look at bug reports, they might
notice it.

The information for maintainers of GNU software agree with me:


    When you receive bug reports, keep in mind that bug reports are
    crucial for your work. If you don’t know about problems, you cannot
    fix them. So always thank each person who sends a bug report.
Which we do but this assumes that everything sent to bug email list is
a bug (they aren't).
See the following paragraphs though:

     You don’t have an obligation to give more response than that,
     though. The main purpose of bug reports is to help you contribute
     to the community by improving the next version of the program. Many
     of the people who report bugs don’t realize this—they think that
     the point is for you to help them individually. Some will ask you
     to focus on that instead of on making the program better. If you
     comply with their wishes, you will have been distracted from the
     job of maintaining the program.

     For example, people sometimes report a bug in a vague (and
     therefore useless) way, and when you ask for more information, they
     say, “I just wanted to see if you already knew the solution” (in
     which case the bug report would do nothing to help improve the
     program). When this happens, you should explain to them the real
     purpose of bug reports. (A canned explanation will make this more
I read the second paragraph as yet another argument in favor of having
a mailing list because this type of discussion (is it a bug or not?) is
better suited there.


How about experimenting with it? We can recommend
GitLab for bug reports on the website during two months
and see how it fares.
This doesn't make sense to me, bug reporting isn't something you do A/B
testing with. Either we decide on something or we don't.

So let me add my two cents to the discussion:
  - I agree with David and the quoted excerpts of "Information for
Maintainers of GNU Software" that we should continue to accept bug
reports via a mailing list. In parts because this is an expectation for
GNU software, in parts because some people might consider it easier
than using a web interface, and lastly because gitlab.com is not
officially endorsed by the FSF (one of the reasons why the main
branches continue to be mirrored to Savannah).

Hm. Non-FSF-endorsement is a good point
(those I'm not replying to are as well).

  - In my opinion, it doesn't make sense to move this type of task to
lilypond-devel - the entire point of bug-lilypond is that reports stay
out of development discussions.
  - Users are already opening issues on GitLab. Maybe it makes sense to
rephrasehttp://lilypond.org/bug-reports.html  to not discourage this
for advanced people, but for all the reasons that James mentioned, I
think it makes sense for bug-lilypond to remain the "default" place
where users report issues / bugs / things they are not sure about.

Why not. How would those involved in this discussion
feel about the following?

diff --git a/Documentation/en/web/community.itexi b/Documentation/en/web/community.itexi
index 0602ddcace..2a75edcd7f 100644
--- a/Documentation/en/web/community.itexi
+++ b/Documentation/en/web/community.itexi
@@ -383,35 +383,30 @@ quite often 4 lines are enough to demonstrate the problem!
 @node Bug reports
 @unnumberedsec Bug reports

 If you have input that results in a crash or wrong output,
-then that is a bug.
+then that is a bug.  We handle feature requests in the same
+way as bug reports; collectively, they form @qq{issues}.

-@subheading Step 1: Known bugs
+@subheading Step 1: Known issues

-We may already know about this bug.  Check here:
+We may already know about this issue.  Check our issue tracker:

 @end example
-@warning{Please @strong{DO NOT} add bug reports directly to the
-bug tracker.  Once an issue has been added to the tracker, feel
-free to add more information to that report.}

-@subheading Step 2: Creating a bug report
+@subheading Step 2: Creating a report

-If you have discovered a bug which is not listed,
-please help us by creating a bug report.
+If you have discovered a bug that is not listed, or wish
+an enhancement that is not listed, please let us know.

-@warning{We only accept reports in the form of
+@warning{We only accept bug reports in the form of
 @ref{Tiny examples}.  We have very limited resources,
 so any non-minimal example will be rejected.  Almost
 every bug can be demonstrated in four notes or less!}
@@ -433,41 +428,56 @@ Here is an example of a good bug report:

-@subheading Step 3: Sending a bug report
+@subheading Step 3: Sending a report

-Once you have verified that the issue is not already known and
-created a bug report, please send it to us!
+If you are certain that your report is not already in the
+database, you may add it to the tracker directly.  Pick a
+short and informative title, and write a description, with
+sample code enclosed in backticks.

-Unfortunately there is no longer an interface for posting to the
-bug-lilypond list without subscribing; see
+Here is a minimal example:
+\version "2.10.1"
+\relative c'' @{
+ bes1 ~
+ bes1
 @end example
-for more information.
+We will add appropriate labels for you.
+If you are not overly certain, or if you prefer email, please
+write to the @uref{https://lists.gnu.org/mailman/listinfo/bug-lilypond,
+@code{bug-lilypond}} mailing list at @uref{mailto:bug-lilypond@@gnu.org,
+bug-lilypond@@gnu.org}.  We will examine your report and add
+it to the tracker if appropriate, taking care of details.

 @subheading Step 4: Wait for a response

-Once your bug report has been sent to the list, our Bug Squad will
-examine it; they may ask you for more information.  You will be notified
-when the report will be added to the bug tracker.  Please allow up to 4
-days, as we have a limited number of volunteers for this task.
+If you sent the report to @code{bug-lilypond}, you will be
+notified when the report has been added to the bug tracker.
+Please allow some days, as we have a limited number of
+volunteers for this task.

-Once a bug has been added to the tracker, you can comment it to add
-more information about it.
-In order to be automatically notified about any activity on the
-tracker issue, you may subscribe by clicking the envelope
-symbol next to the issue title.
+Once an issue is in the tracker, you can comment on it to
+add more information about it.  If you have not created
+the issue yourself, you may choose to be notified about
+any activity on the issue using the dedicated button in
+the right pane (after logging into GitLab).

 @subheading Optional help: show the desired behavior

-Once an issue has been added to the tracker, it can be very
-helpful if we can see the desired output.  Feel free to add input
-code and/or images (possibly created with other tools) which
-demonstrate what you think it should look like!
+A helpful adjunct to a bug report is the desired output.  Feel
+free to add input code and/or images (possibly created with other
+tools) which demonstrate what you think it should look like!



reply via email to

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