On 2014-07-12 at 01:05 +0100, Michael Grant wrote: > Out of curiosity, what version of unix/linux is exim developed on anyway?
There's a team of people who do most of the work; Todd Lyons and Jeremy Harris are driving most of the recent work, you'd have to ask them. I drove several releases, and I primarily use FreeBSD for personal stuff, so a number of features were written there and ported later. The original author, Philip Hazel, mostly used Sun systems, but did switch to Linux at some point. An important point is that thanks to Todd, we now have a buildfarm of agents building Exim on various platforms and submitting responses back to a tracker, so we can tell when builds and the test suite fail on a particular OS. So if we read "developed on" as "we know quickly when things break, so that we don't find out during or after a release that we broke a particular OS" then the answer is "any OS which has an agent in the build farm". http://eximbuild.mrball.net/cgi-bin/show_status.pl At present, that's "varieties of Linux", "FreeBSD" and "OpenIndiana". For every other OS, we only find out about problems if users of that OS are actually testing the Release Candidates of Exim, or in a worst-case scenario (which does happen) when the first time someone using a particular OS tries to build the final release of Exim and reports back problems. For more details, see the EximReleasePolicy wiki page, linked to below. On 2014-07-12 at 19:21 +0100, Michael Grant wrote: > So I see, I am starting to understand now that there is not an exact > relation between the dot releases in exim and the release numbers given in > debian (or any unix/linux distro for that matter). You might want to read the "Release numbering" section at https://github.com/Exim/exim/wiki/EximReleasePolicy A third number is only used when there's a significant security issue which needs to be addressed as fast as possible and we don't want users and admins also fighting any possible regressions which might slip in. For those cases, we backport the fix to the codebase at the time of the last release and issue a .1 release on top of that. Eg: http://git.exim.org/exim.git/shortlog/refs/heads/exim-4_80_security Exim security issues, to look for in changes elsewhere, should be collected at: https://github.com/Exim/exim/wiki/EximSecurity > Yes, I agree and for me, a dot release is not a major release. But I'm > understanding that you are referring to ANY change in the version number > you consider a major version upgrade. Yes, this is normal: the OS distributions focus on making their supported product as stable as possible. A fairly common and sensible approach is to use your OS vendor's packages for Exim on any machines where email is not the primary purpose, but if you're running a large mail-system to build your own Exim there. I've found that when running various sites and services this is actually a good way to structure the division between "we maintain" and "we accept OS updates": the software components of the core service you are providing, you make sure that your team is tracking security issues, announce lists, and that you can rebuild your production stack fast and push out changes with exactly the changes you qualify, on little or no notice. For everything else, you leave it to the OS distributors, whose priorities differ but generally do a good job. If you're running a high-profile website, you probably maintain your own builds of the web serving stack. If you're running an ISP mail-system, you maintain your own builds of Exim. Perhaps "own builds of anything that exposes a listening port to the outside world and if we take it down, customers notice and it's damaging to us". But you don't want to take this too far, as you quickly move away from the improved benefits of tailoring your software stack to your needs and getting security fixes out even faster, instead moving towards just reproducing the good work done by the OS distributors and taking away time and resources that could be spent moving forward elsewhere. The Debian maintainers of the Exim packages are particularly good at tracking issues and working with the Exim devs on any problems. > So how can I know that any particular distribution is patched up to the > current bug fix level of the current level of a piece of software? Read the changelog for the package for that OS; if the changelog is useless, decide if that OS vendor is really providing the support you want. There are a variety of vendors and if you need something in particular, you can always pay for it. > some time trying to search out this info in the svn repo for debian and > couldn't find it. I see it's been updated 4 times but without actually > digging into the diffs, there seems to be no easy way to know. I just used Google to search for "Debian Wheezy Exim changelog"; one of the top results was <https://packages.debian.org/wheezy/exim4-daemon-light> and on the right-hand side of that page, there's a link "Debian Changelog": http://metadata.ftp-master.debian.org/changelogs//main/e/exim4/exim4_4.80-7_changelog -- My employer, Apcera Inc, is hiring sysadmin; primarily San Francisco: http://www.apcera.com/jobs/#operations-engineer (but all the mistakes in this email are made in my personal capacity) -- ## List details at https://lists.exim.org/mailman/listinfo/exim-users ## Exim details at http://www.exim.org/ ## Please use the Wiki with this list - http://wiki.exim.org/
