Proposal/Guidelines for working on *-security branches in packaging repository
Hi
I was pondering for a while to try to start this discussion. And it is
more a collection of some thoughs.
Recently more people have started to work to as well commit fixes for
CVEs into the respective *-security branches. This is very good news
indeed :) and is very encouraging to see contributions!
I started to think we might want to outline some guidelines what to
commit on *-security branches while we are yet UNRELEASED.
Two preliminary points have to be stated to make the idea clear:
- Not every CVE fix needs really a DSA or an "urgent" release via
security, many fixes go in as well via import of upstream stable
releases and scheduled in point releases.
- If a security upload needs to be done, and there is in particular an
ABI bump involved, then more needs to be done (bump ABI, make a new
linux-latest upload, packages need to go through NEW on
security-master and need manual intervention from ftp-masters, the
later is as well then in twice instance needed for now from
ftp-masters for signed kernel as well).
So my idea was to bring this up here for discussion: I think while
working on *-security branches and keep the possibilty to release
"fast" updates without ABI bump via security, whenever needed for an
"urgent" fix -- I would propose as guideline -- commits can, and are
*encouraged* to be added, if there is no ABI break. If there is an ABI
break and the fix is not very urgent, then rather keep if off for the
time beeing.
Whenever then an urgent fix is needed which in any case requires an
ABI bump then it's safe to add as well other less urgent commits for
CVEs.
So as idea "try to always keep *-security branches safe for 'easy to
process' uploads.
What contributors think? Does this make sense to have somewhere
written properly out and documented?
Regards,
Salvatore
Reply to: