On Sat, 20 Sep 2008, Simon L. Nielsen wrote:
- The more branches are supported, the more versions of both third party code and FreeBSD code need to be supported and the more likely it is that the software differs meaning that we need to adopt the fix to the branch. The real painful case for this was FreeBSD-SA-07:01.jail which AFAIR needed 6 different patches. This is one of the largest time cost with support many branches as this is by no means a linear cost. The older a branch is, the more likely it is that the code is much different than newer FreeBSD versions. This also the reason secteam was very happy when we could discontinue FreeBSD 4 support as it was significantly different from FreeBSD 5+. In that respect supporting FreeBSD 5 in the end was much cheaper than supporting FreeBSD 4 in the end. Of course this is less likely to be a problem in the future like it was with FreeBSD 4, but still - FreeBSD 5 and FreeBSD 8 are rather different and would not be fun to support both.
Let me give an example from a slightly older branch here as well: we de-supported FreeBSD 3.x for "local" security vulnerabilities because we hit the libncurses security vulnerability. The only real option to pick up the fix was to adopt new version of libncurses, and that radically changed the libcurses API (part of the fix). This, in turn, cascaded into other applications, such as top, vi, etc, which all use ncurses, so the net effect would have been not just a significant API change, but also modifications to countless system utilities. Such a change might not even be appropriate for a minor branch, let alone a security branch where we try to ensure minimalist fixes to avoid security patches leading to other potential regressions.
Robert N M Watson Computer Laboratory University of Cambridge _______________________________________________ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
