Re: What is the point of bug-lilypond?

[Jean Abou Samra]

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