bug-lilypond
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: What is the point of bug-lilypond?


From: James
Subject: Re: What is the point of bug-lilypond?
Date: Thu, 14 Oct 2021 06:43:40 +0000

Hello,

My own thoughts on this.

On 14/10/2021 01:31, Jean Abou Samra wrote:
Hi,

After having opened a few GitLab issues in response to
bug reports on bug-lilypond, I find James extraordinarily
patient for having done this over the years. However, I don't
get the value in this system compared to letting people
creating issues on GitLab directly. When we transfer an
issue to GitLab, it's usually just pasting the text from the
email report.

No it is more than that.

It is parsing said bug report - is the thing you are reporting valid? Is it just something a user needs to ask on a different list (e.g. the user is expecting X and is getting Y because they don't understand something but LP is working correctly), is it actually working as designed where the design is not broken but just a hard problem to solve and so on. My day job involves having to tell end-users over and over that X is actually correct because 'reasons' and, at the same time, trying to understand why users think X is a bug when it is not (perhaps improved documentation is all that is needed). So perhaps I am good at this because I have had 20+ years of having to explain this kind of thing to non-technical (or mostly non-interested) people.

Sometimes emails to the bug take the form of 'I do X is this expected or is this a bug' which again requires a slightly different tack.

I would say that 'most' emails to the bug list do NOT need an issue, they are either replies to emails or pointers to existing Issues that explain bug or technical discussions about why something is not a bug but a limitation of what is possible based on how we code things (which itself engenders more emails).


Right now, bug reports often take a week to be acknowledged,

Maybe but what's the rush? It's not like we have KPIs or Sprints to complete or other arcane methodologies to acknowledge to release LP. The information is there, it isn't going anywhere, if someone fees THAT strongly about wanting conformation (or usually affirmation) then they will just reply to their own emails and someone will look,

and some of them are not acknowledged by us at all. Take
https://lists.gnu.org/archive/html/lilypond-user-fr/2021-01/msg00014.html
reported 9 months ago, which I just added to the tracker.

Which proves my point although this is not from the bug list this is  a user list. So the report is not being put to the correct list in the first place. I like the separation of lists (user, dev, bug) I don't subcribe to the user list at all in fact (I am not that interested) and I knew that some developers don't subscribe to the bug list for their own good reason.

I am not saying we will catch everyone in a timely manner but we do a pretty good job considering (and this bug was reported on the user list).

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.

The information for
maintainers of GNU software agree with me:

https://www.gnu.org/prep/maintain/maintain.html#Replying-to-Mail

   When you receive bug reports, keep in mind that bug reports are
   crucial for your work. If you don’t know about problems, you cannot
   fix them. So always thank each person who sends a bug report.
Which we do but this assumes that everything sent to bug email list is a bug (they aren't).

In spite of us not advertising this as a way to report problems,
a number of users have been creating issues on GitLab themselves,
likely because that has become enough of a standard in other places.

When replies are made on bug-lilypond, someone has to paste
them on the ticket as well, for completeness, which leads to
an awkward split where one does not know where the discussion
is supposed to happen or whether the other person has read
a remark on the other channel.

But that has always been a problem and will always remain a problem (again I refer you to the bug report you found on the user list, the French user list as well, which is even more removed) also how many times have things been sent to the other user lists or dev lists or even direct to Han-wen/Jan et al? Again I think this is not that big a deal.


So how about retiring bug-lilypond and directing to GitLab
instead? Tickets can be triaged there, closing invalid ones,
adding a minimal example if not present, perhaps changing the
title. The requirement from the same page of GNU guidelines,

I don't see the difference between triaging GitLab vs triaging Bug apart from the fact that it is very easy to use bug-list interface to track email threads - it's so easy to spot of something on the bug list has had a reply or not. I haven't use GitLab's interface that much to follow conversations (which is what 90% of bug is) but if the rest of the interface is anything to go by, I expect it will be a mish-mash of type styles and clours, coloured labels, icons and other tiresome artefacts that plague the modern web these days.

That said, historically we had a group of non-technical people, like myself, that could just use email or use the simple bug-list interface to keep track and check so-called reported bugs. Alas those people have disappeared over the years so the work is being done by us all now who are more technically minded or don't despair about using these 'GitHosty' interfaces.

I can reply-all to emails, can I do the same thing to whatever this is or do I need to use a browser and log in and click somewhere to open a window to type my reply and then and then and then ...?


--
Regards

James





reply via email to

[Prev in Thread] Current Thread [Next in Thread]