lilypond-devel
[Top][All Lists]
Advanced

[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 10:39:33 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.1.50 (gnu/linux)

address@hidden writes:

> Updates:
>       Status: Verified
>
> Comment #14 on issue 2653 by
> address@hidden: Midi output
> does not respect tied notes
> http://code.google.com/p/lilypond/issues/detail?id=2653
>
> David, "Verified" means "this issue is over and done with and nobody
> should ever need to look at it again".  "Invalid" means "please check
> this and see if you agree with me".  (I agree that this is not
> optimal, but that's how this issue tracker works)

Then we need to change the descriptions in the tracker.

Closes Statuses:

Fixed: Developer made requested changes, QA should verify
Verified: QA agrees with the developer
Invalid: This was not a valid issue report
Duplicate: This report duplicates an existing issue

It is obvious that changing "Duplicate" to "Verified" would be a mistake
since it would lose the connection to the issue linked as duplicate.
The usual job of QA is to make sure that the developer's intent is
reflected in code and repository.

So both with respect to the status descriptions as well with what I
consider useful, figure me surprised.  At any rate,
<URL:http://code.google.com/p/lilypond/issues/list?can=1&q=status%3AInvalid>
cranks out a list of 44 "Invalid" issues.  According to the stated
policy, those should be marked "Verified" eventually.  That presumably
means that QA needs to check the reasons for marking the issue "Invalid"
and make a decision about a validity of reasoning (rather than, as
usual, a verification of state), then remark as "Verified".

To me this seems both like an untypical requirement towards QA, as well
as making the tracker less useful for figuring out the state of an
issue.

Where can I find more about the reasoning of this policy that is not
apparently actively pursued, judging from the current state of the
tracker?

-- 
David Kastrup




reply via email to

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