[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: What is the point of bug-lilypond?
Re: What is the point of bug-lilypond?
Thu, 14 Oct 2021 06:43:40 +0000
My own thoughts on this.
On 14/10/2021 01:31, Jean Abou Samra wrote:
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
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
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.
Which we do but this assumes that everything sent to bug email list is a
bug (they aren't).
The information for
maintainers of GNU software agree with me:
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.
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
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 ...?