Issues with the issue tracker

• Feb 13, 2018 - 17:33

I have a couple of issues with the issue tracker.

  1. Several issues have a status of Patch (Code needs reviewed) or Patch (Ready to commit) with no further status updates. Some have been this way for years. It is now impossible to look at the list of issues and see how old they are (see #2)

  2. When Version 2.1 was released, all issues listed as being from a version prior to 2.1 were changed to version 2.1. This is confusing if you are trying to research an issue. If the issue came up under a 1.x (or prior) release it is still listed as being applied to version 2.1, even if 2.1 never needed this issue reported against it. You cannot go by the date it was last updated because there are issues that were dormant for 4-5 years and suddenly someone decided to make a comment on it. The issue is dated as the date of the last comment.

  3. Issues entered in error (such as #268700: Altération) should have a status that indicates it is bogus, rather than closed. It is impossible to tell the difference between a fixed bug and a bad bug report. In order to test changes between version 2.1 and 2.2 (which should be released soon) one must sort through every closed issue and determine if it was fixed or if the issue should never have been reported. I would suggest all bogus but reports be changed to Category: Support Request with a status of Won't fix or by design.

Fixing these issues lead to making it easier to test items that have been identified as fixed in the issue tracker without having to read unnecessary bugs and feature requests.

Comments

• Feb 13, 2018 - 19:55

I should have mentioned that I'm aware of the documents concerning 2.2. I refrained from saying that these issue I raised are for the most part insane and should not exist. Why would an issue from 1.x be listed as a 2.1 issue? Fixing what was done in the past is not a realistic expectation. I hope they are not repeated after the release of 2.2. If the issues I mentioned were fixed, it would be simple for anyone to look at the next release's documents and ensure that all of the fixes are listed in the documents and testers such as myself could see what might be in need of testing to assure the fix is as expected. In short, fixing these problems will make it easier in the future for everyone.

I'm probably not unique in that I don't download the latest update every night but occasionally download a nightly and use what seems to be a relatively stable version for my daily work. In doing this, I can test it in an actual use situation, rather than in a laboratory of controlled conditions which is important to narrowing a known bug, but not useful for finding other bugs.

On the first issue, concerning Patch(...), in most of these cases you are the one who should do something about the status, either merge it or reject the PR and change the status with an explanation. The one that inspired this post was actually an exceptional one, but should still not have been in limbo for 5 years.

I do want to add that I appreciate all of the work that you, Werner and the rest of the contributors do to make MuseScore and outstanding program and I look forward to it continue to improve in the future.

Reply

• Feb 14, 2018 - 16:57

On the first issue, concerning Patch(...), in most of these cases you are the one who should do something about the status, either merge it or reject the PR and change the status with an explanation.

You are right. Let's say I prefer to say nothing than no and sometimes it's just easier and faster for me to not give an explanation and let it open instead of giving an explanation that will just be discussed for days. I guess I need to fix this behavior.

Reply

Do you still have an unanswered question? Please log in first to post your question.