--On 06 September 2005 10:16 +0200, Stephan A. Rickauer wrote:
There is one thing I still don't understand. What effort is it to deliver patches (not backports) longer than just a few month - given that the overall amount of patches per release is low with OpenBSD anyway... let's say you have four security relevant patches per release, then you had 20 in 2.5 years ...
Some problems could be addressed quite simply in an older system, but having that as the stated policy means that all problems fixed in newer code would have to go through a procedure something like: Decide on the severity of the problem as to whether it needs fixing in older code, Check which released versions are affected, Produce and test patches for all of these, Distribute patches, Notify users where security-critical, etc. In areas of code which have undergone major change, just backporting the fix can be quite a task.
This may be ok for a vendor, who can dedicate staff to the process of maintaining what, 6 or 7 trees (though some vendors don't seem to do particularly well at the 'test patches' stage), but doesn't seem to fit well with how OpenBSD is developed - fixing problems seems at least equally important as adding new features, so that's a lot of time spent analysing (e.g. as to whether a particular problem fixed might affect security). The people who are capable of that type of analysis usually can find more productive ways to spend their time.
But think of applications servers that run all weired kind of things ... it is a nightmare to upgrade those every half a year (not speaking of *patching* - only saying that since some posts seem to treat patching and OS upgrade similarly).
There doesn't have to be so much difference, actually. With OpenBSD an upgrade is usually pretty straightforward. The main part of the process (boot from bsd.rd, run the 'upgrade' process) can equally be used for patches and upgrades. With an upgrade the initial step is to read updateXX.html, with a patch you can first create distribution *.tgz files using 'make build' and 'make release' and host them on local ftp (a bit of overkill for one or two machines, but invaluable on a larger network).
Obviously there have been major transitions (a.out to ELF, for example) where greater care has to be taken, but these are unusual and well-publicised. Perhaps they can be taken as a cue to carry out a more involved rebuild rather than a simpler upgrade (which often gives a chance to refactor and simplify a complex organically-grown system). With an application server, you often have to pay so much attention to keeping the parts other than the OS up-to-date (which of course are the parts with the most custom configuration), that the time spent on the OS is pretty low in comparison anyway.
