Re: What is the point of bug-lilypond?

[Jonas Hahnfeld]

Am Samstag, dem 16.10.2021 um 16:33 +0200 schrieb Jean Abou Samra:
> > > > 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.

I would interpret this fact as "the current process works" (mostly).

> > > >    - 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?

I would *only* change the "DO NOT" warning above to maybe "If an issue
has already been added to the tracker, feel free to add more
information to that report." as normal text, without the warning box.
The rest of the page should stay 1:1 the same, in my opinion we want to
send users to the mailing list by default.

signature.asc
Description: This is a digitally signed message part