[Top][All Lists]

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

Re: Issue 2653 in lilypond: Midi output does not respect tied notes

From: David Kastrup
Subject: Re: Issue 2653 in lilypond: Midi output does not respect tied notes
Date: Tue, 17 Jul 2012 12:07:29 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.1.50 (gnu/linux)

Graham Percival <address@hidden> writes:

> On Tue, Jul 17, 2012 at 10:39:33AM +0200, David Kastrup wrote:
>> So both with respect to the status descriptions as well with what I
>> consider useful, figure me surprised.  At any rate,
>> <URL:>
>> cranks out a list of 44 "Invalid" issues.  According to the stated
>> policy, those should be marked "Verified" eventually.
> Yes.  Actually, I thought that I was going to stop making any
> devel releases if there were still "issues to verify" waiting
> around, but I must admit that I haven't been checking this lately.

I am by now reasonably sure I remember that this has been discussed at
some point of time and did not catch my attention.  So I apologize for
the show of utter surprise I put on here: it is likely that I already
would have had opportunity to comment at a more imminent time.

It does not appear, however, that at least the current behavior of the
tracker with regard to searching "Issues to be verified" and the
description of the "Verified" status make it a good idea to pursue that
policy.  And I don't see that the policy is reflected in our
contributors' guide.

I can't tell whether the behavior/description of the tracker at one time
would have favored verifying issues marked as "Invalid".  At the current
point of time, however, this would not appear to be the case.  If a
developer states something akin to "Gould declares that noteheads should
appear to both sides of the stem in this case, so we won't change the
behavior" (not an untypical response to a request to change existing
behavior), I don't see how the BugSquad can be expected to verify.

"Verify" should mean more than "the BugSquad has verified that the
developer is able to use the bug tracker": this would not work reliably
since it does not catch the case where the developer marks a bug as
"Verified" himself.

So whatever result a possible previous discussion might have arrived at,
it does not correspond with the instructions in the CG.  And in this
case, I consider it more prudent to change the purported result of the
discussion rather than the CG.

Again: it is very definitely possible that I have had ample opportunity
to state an opinion before, and I apologize for not previously bringing
forward the opinion I do now, and possibly for bringing my now-formed
opinion forward in a manner that has been more belligerent than called

David Kastrup

reply via email to

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