Here is a reference for what the bug statuses used on this tracker are, and how they should be used.
The default status. Somebody has reported the bug or feature request, but no developer looked at it or triaged it yet.
The developer requires more feedback before proceeding (to be able to reproduce the bug, for example). This usually means it's waiting for the initial reporter to add a comment with the needed information, but somebody else could provide that feedback too.
A bug could go from New to "Needs feeback", but could also go from Confirmed/In progess to "Needs feedback", depending on when the feedback is needed.
The developer who put the bug in this state should be the one who takes it out of this state too (unless it's being assigned to somebody else). It should not be the reporter.
The bug has been confirmed by a developer. However it hasn't been assigned to anybody in particular yet, so work has not started per se. We could assign a target milestone to the bug at this point.
Work has started to fix this bug/feature. At this point it should be Assigned To somebody. A target milestone should also be set, unless the bug is expected to be fixed very quickly.
The developer believes the initial bug/feature request has been fixed in the git tree. If the bug still happens, the reporter can re-open it (set it to New again), by adding a comment.
If the Redmine project is linked with the git tree of this particular project, you can add "fixes #18" or "closes #18" somewhere in the commit message, and it will automatically put issue #18 to Resolved.
The bug report or feature request is invalid, in the sense that it is not a bug. Some trackers call this NOTABUG. It is the opposite of "Confirmed".
This is used for example if nobody other than the original reporter can reproduce the bug (which would indicate a problem with their installation, not the program), or if there is a bug but it is not in LTTng itself (bug in libc or Python, etc.)
It's still interesting to keep those issues (don't Delete them!), because then we can point to it when similar issues arise, or we can link to the bug in the external project from it to follow its progress.
While Invalid is for stuff that can not be recognized as a bug, "Won't fix" can be used for recognized bugs, but for which the impact is so small and the amount of time required would far overweight the benefits. Ideally, "Won't fix" bugs should be kept at a minimum ;)
A "Won't fix" feature request on the other hand would be useful where the developers would not want to implement a feature because it goes against the design.