On Thu, Dec 31, 2015 at 01:13:19PM +0100, Guido Günther wrote: > Hi release team, > on the LTS list we discussed if it would be feasible to have the same > nspr/nss[1] upstream version in all suites (nameley testing, stable, > oldstable, oldoldstable). There are several reasons for this: > > * Doing so would reduce the number of embedded code copies in > icedove/iceweasel/chromium/.... They currently become necessary at > one point once the version shipped in stable becomes too old. > > * NSS receives frequent security updates that currently requires > backporting the patches to very different versions > > * Backporting NSS patches becomes much harder over the years so > introducing a new version might become less risky than doing the > backport. > > * NSS/NSPR have strict ABI policies[2] to not break backward > compatibility. > > * Security bugs are often restricted on the mozilla bug tracker for > a long time so we know there _is_ a bug but might not know what it > is until the bug is publicaly accessible. > > * We would have the same crypto policies for programs linked against > nss in all suites. > > As a first step we discussed if it would be possible to introduce the > new nspr/nss versions via stable point releases. This would allow us to > ask for testing via the proposed-updates repo while still being able to > fix any regressions via a DSA. Backporting would become simpler since > the same backporting would happen for stable/oldstable and oldoldstable > and the diff to the new upstream version is minimal. > > In order to improve confidence in nss upstream releases we enable the > test suite during the build and added some basic autopkg tests[3,4]. > > Would it be o.k. for the release team to handle new nss/nspr versions > via stable point releases?
Now that squeeze moves out of support would it be o.k. to update nss via p-u for stable and oldstable? Cheers, -- Guido
