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)
