[email protected] writes: > Updates: > Status: Verified > > Comment #14 on issue 2653 by > [email protected]: 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 _______________________________________________ lilypond-devel mailing list [email protected] https://lists.gnu.org/mailman/listinfo/lilypond-devel
