Which tickets need to be fixed before release? I think tickets 2,3,6 and 7 are the most important ones.
I think 2, 3 and 18 are pretty critical.
17 should get split into tickets for the respective light groups, it is too vague and will always need further explanation like it is now. We can't implement every light without punishing the GPU. Also we should include the engine light sources into the planning, the engine lights have a higher priority than the other lights during ascent, but can be removed afterwards.
(Suggestion: New Ticket for "Implementation of a LightSourceManager class" for managing the light sources that are enabled/disabled in one place, instead of having the functionality spread over multiple places)
9 sounds pretty bad to me, but the "open" status sounds misplaced there. A code review could find the possible origin of the problems, if it really still exists. Or somebody should do brute force tests for buffer overflows for an evening (2-3 hours, not more), if this doesn't show any problems, the ticket should get closed and not get opened again.
#11 is my responsibility, I will look at what I can do there, but it is not release critical at all IMHO.
################################################################################
About the ticket format: In the future, tickets should always be formulated in a way, that we have a "definition of done" in the text: What should SSU do, how must it behave, so this ticket can be considered closed? Like it is now, we can't test if a ticket is really closed.