During the monthly LTS meeting Emilio mentioned that we should reconsider our approach to <no-dsa>.
The specific statement was: "I feel like we're giving ourselves too much work by tackling no-dsa issues on LTS, then forcing ourselves to fix them in stable. maybe we need to revisit our no-dsa policy" We have generally made an effort to try to fix <no-dsa> CVEs, or to re-triage them as either <postponed> or <ignored> when those other designations are appropriate. For the purposes of this discussion it seems safe to include <postponed> along with <no-dsa> as they both essentially mean "fix later". As has been observed (not only by Emilio in the meeting, but by others at various different times), if we elect to fix a <no-dsa> issue in LTS, then we generally need to fix that same issue in stable. If the CVE is not fixed in stable then there is a possibility that a user may experience an upgrade regression. This happens when a CVE is fixed in an older release and then when the upgrade to a newer release is performed that CVE is suddenly no longer fixed in the new system. This is an undesirable situation that we want to try to avoid. With all of that in mind, I am interested in the thoughts of everyone on the team, both for an aggressive posture towards fixing <no-dsa> issues, and for a more relaxed posture where we allow more <no-dsa> issues to remain unfixed (presumably those which are of lower importance). I am also interested to know whether people think that our more clearly defined "(un)stable-first" approach to package updates might make this less of a pressing issue going forward (because we would be landing fixes in stable before* landing them in LTS). * Which may actually mean "landing fixes in the PU queue before landing them in LTS"). At this point I don't know that we are ready to make any major changes, but I am genuinely intersted to see where this discussion goes and what points are raised. Regards, -Roberto -- Roberto C. Sánchez
