[Nix-dev] Policy for updates in 14.04

[Peter Simons]

Hi Lluís,

 >>> Almost any software update will contain a bunch of bugfixes and only
 >>> sometimes new features.
 >>
 >> can you point me to an empirical study that supports this thesis?
 >
 > I mean the impression I got from reading release notes of different
 > programs. For example:
 > https://gitweb.torproject.org/tor.git?a=blob_plain;hb=release-0.2.4;f=ReleaseNotes

well, that sample size seems not exactly statistically significant. ;-)

Anyway, having said that, I believe that update that improves security
should be applied if the risk of breaking an installed system is
small'ish. Personally, I'd rather have a broken system than a running
one that can be exploited. I believe most people feel that way, and
those who don't can always follow 'master' and live in the wild west.

Still, I would like to distinguish between security updates that fix a
particular vulnerability (i.e. they refer to some specific CVE) and a
general kind of update that may improve security in some vague
unspecified way. The first type of fix is a no-brainer, IMHO, and should
be applied quickly. The second type of update, however, is trickier to
decide, because one has to balance the gains of an improved piece of
software against the costs of updating.


 > For some software, the stable branch does not run into much more
 > tests than master. And at some point, master becomes the new stable.
 > There is no gathering of signatures from maintainers testifying that
 > "it works" or similar.

It is true, though, that we -- the NixOS maintainers -- make a serious
effort to stabilize 'master' before we branch off a release, no? There
was a flurry of activity before 'release-14.04' was created, and people
also made an effort to hold off any commits to 'master' that might
destabilize the system.

Now, when we merge updates from 'master' into that release branch long
after it was created, then we take the risk of introducing
incompatibilities between software versions in that branch that don't
exist in master (because some of its core packages have versions). I
think it's smart to minimize that risk by updating conservatively.


 > My argument is that I don't think that having very strict policies of
 > update will not make the stable branch relevantly safer.

There is the problem that packages foo-Y and bar-Z work fine on master
(because they interoperate nicely), but when someone merges bar-Z into
the release branch without merging foo-Y as well, then we'll run into
trouble because the release branch has some older version foo-X that
subtly fails to interoperate with bar-Z.

I have no idea how often this kind of problem exists, but I believe that
it could exist, especially when 'foo' is some kind of shared library,
like boost.


 > I make a distinction about "system packages". If I update a
 > bittorrent client in the release branch, having tested it, should do
 > no harm.

Yes, this is true. I completely agree.

Best regards,
Peter