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
_______________________________________________ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
