Open Tickets in Catch Bug Tracker

[ianmacs]

Catch has 214 open "Issues" on github.

Nothing wrong with that per se, but going through the list I note that many of them could be either closed or marked as feature request.

I'd like to share my Impression with Phil so he can maybe save some time dealing with the Issues.

The following Issues have been resolved (fixed or declined) and can be closed, but the ticket is still open:
#665, #620, #600, #584, #574, #573, #572, #560, #525. Maybe also #593, #590, #565, not sure.

The following remind me of support requests. They could be closed with a hint to ask the forum if the question is still relevant: #671, #666, #632, #621, #612, #607, #603, #576, #569, #567, #552, #547, #542, #539, #536, #531, #529, #522, #516, #515.

Then there are a lot of feature requests. This shows that people like using Catch, and would like it even better if it supported just one more feature. It is of course completely up to Phil how to deal with these. If I were in his place, I would close the ones that are not on my roadmap, saying so, and label the remaining ones as feature requests, if this is supported by the github bug tracker, so they do not count as open bugs. These are: (Performance:) #668, #556, (Output:) #664, #663, #639, #638, #613, (TestingTools:) #652, #651, #642, #641, (Test Runner:) #645, #629, #622, (Cosmetic:) #610, #609, #601, (Esoteric:) #644, #640, #611, #605, #589, (Other:) #582, #558, #553.

This here is caused by bugs in third-party software and can be closed in the catch Bug Tracker: #661.

These bugs show up when using outdated or exotic compilers or targets. They could be closed, stating that Catch does not target these compilers / platforms: #674, #649, #594, #583, #579, #575, #543.

I would classify the following bugs to have a low priority, as they are unlikely to affect the main function of catch (perform tests reliably:) #625 (output), #617 (cosmetic), #615 (const correctness), #586 (debugger support), #578 (language lawyer case).

Some of the following have been mentioned above, some not. I find their info relevant enough to test the respective situation myself with the compiler and platform that I intend to use before committing to use Catch myself: #649, #602, #594, #593, #590, #583, #579, #575, #543,
#574 causes me to add a coding standard rule that testing objects with custom (&&,||,!) operators (which I cannot envision why I would have that) inside Catch macros is not permitted.

Oh, I only got as far back as #515. Not sure if I will continue, or chose another unit testing library.

[lightmare]

label the remaining ones as feature requests, if this is supported by the github bug tracker, so they do not count as open bugs

Issues may be assigned arbitrary custom labels, which means it's totally possible (and helpful) to do what you did here directly in the tracker. They'll still count as open issues, but anyone can filter what they're interested in, e.g. see only bugs (only acknowledged, as it still requires the maintainer to take a look at each issue and assign appropriate labels).

[philsquared]

I've had to focus elsewhere for a while but I'm going to start catching up a bit (pun intended) now.
Categorising the open issues with labels sounds like a good idea

[philsquared]

I think it's finally time to close this ticket.
Thanks for bring this up and all the work you put into it, @ianmacs.
We're down to under 130 open issues now (and still steadily working through them), and (at time of writing) all of those have been categorised with tags. I think things are going in the right direction (mostly thanks to @horenmar).