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

Le 16/10/2021 à 16:03, Jonas Hahnfeld a écrit :
Am Samstag, dem 16.10.2021 um 15:49 +0200 schrieb Jean Abou Samra:

Honestly, it doesn't make sense to extrapolate from you to others. I
certainly do if I'm interested in the history of particular decisions,
and I think I've shared collections of links for past discussions.

There is no point in discussing this if we've agreed
on the resolution.

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.
Pointing to bad experiences with other projects is not exactly a
convincing argument to me with respect to LilyPond.

I gave an example with a LilyPond user above.

Given that I have for some time not frequently been
wondering if something in LilyPond was a bug where
others could tell it to me, it is not easy to find
anything better.

   - 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
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
   @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}.
I think this is unrelated to the current discussion. It definitely
feels wrong on a page titled "Bug reports".


-@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.
No no no! Everybody thinks their problem is unique and is absolutely
"certain" about that, that's why we can also use bug-lilypond to
deduplicate reports.

Can you propose a better phrasing, please?

-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.
I proposed "not discourage", the wording here is towards "prefer
GitLab". I don't think this is the right way to go.

Same: how do you propose to phrase it?


reply via email to

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