Paolo Prete <paolopr...@gmail.com> writes:
On Thu, Jun 25, 2020 at 6:00 PM Jean Abou Samra
<j...@abou-samra.fr>
wrote:
So, in order to produce a concrete result, at least the
point
2) should be accepted / understood. This is what I tried
to
do, but the thread seems to go in the opposite way. This
is
why I think that opening a ticket would be unuseful for
now
and I did not open it. But if you think it could be
useful,
be free (of course) to open it ...
This is precisely the heart of the question. LilyPond
development
is
(mostly) not driven by the importance of issues but rather
by
pleasure and
interest. Which means that you just need one person willing
to
spend time on
piano pedals − and skilled enough for that − regardless of
the
issue's
weight. That can happen now, or in months or in years, who
knows.
In the
most extreme cases, issues can be resolved a decade after
they
were
reported. Look at the one David Stephen Grant fixed just two
weeks ago:
https://gitlab.com/lilypond/lilypond/-/issues/1722
https://gitlab.com/lilypond/lilypond/-/merge_requests/119
This is why issues are so essential. They help organize work
on a
long time frame.
By the way, the Type::Enhancement label expresses no
judgement
about wether the
issue is a major one. It's to be understood as opposed to
Type::Defect: this ticket
is about an enhancement because the current output is
consistent
and there is
no crash.
I opened https://gitlab.com/lilypond/lilypond/-/issues/6005
.
I would not proceed in this way.
The lack of a cautionary pedal on a bracket could be seen as an
enhancement only in a self-referential context, which doesn't
make
sense to me. A proper way to proceed is to check what modern
professional engravers do with it, and check as a consequence if
Lilypond is coherent with them (-> common practice)
AFAIK nobody uses a bracket without a starting word in
professional
engraving, it would have too many bad side effects. And opening
an
issue as an enhancement IMHO will weaken the urgency of fixing
this.
Best,
P
Certainly you're right that it's an "enhancement" only in a
self-referential context. But that was already the meaning of
Jean's message; when you decide to use *any* complex software
that's developed by volunteers, you must accept that this same
self-referential point of view is going to prevail. It's just part
of the way humans are. The main exception is when someone is
bothered by an irritating defect that he cares about, in some
software that he cares about; he refuses to accept that the
situation might stay this way, and finally he gets so impatient or
angry that he learns the necessary programming language and fixes
the problem himself. (Who knows? That example might be you!)
There's an old joke: When free software is defective, the users
are entitled to a full refund. :)
--
David Rogers
