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:
https://lists.gnu.org/archive/html/guile-user/2021-06/msg00065.html
https://lists.gnu.org/archive/html/guile-devel/2021-07/msg00001.html
https://lists.gnu.org/archive/html/bug-guile/2021-08/msg00007.html
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
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
-
@divClass{heading-center}
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".
@divEnd
@divClass{column-center-top}
-@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:
@example
@uref{https://gitlab.com/lilypond/lilypond/-/issues}
@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.}
-
@divEnd
@divClass{column-left-bottom}
-@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:
@divEnd
@divClass{column-right-bottom}
-@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
@example
-@uref{https://lists.gnu.org/mailman/listinfo/bug-lilypond}
+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?
Best,
Jean
