How much no-dsa is too much no-dsa?
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
Reply to: