Re: What is the point of bug-lilypond?

[Jonas Hahnfeld]

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

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.

> 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:
> 
> 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.

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

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

>   @divEnd
> 
>   @divClass{column-center-bottom}
>   @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).
>   @divEnd
> 
>   @divClass{column-center-bottom}
>   @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!
> 
>   @divEnd
> 
> 
> Regards,
> Jean
>

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