Philip Hazel has been the major developer since Exim started in 1995, although he has often taken contributions of code from others and merged them into the development line. However Exim has been very much the product of a single co-ordinating developer.

Things are now changing with Philip intending to take a less central role, and a group of developers getting involved in taking Exim forward.

Exim has always been based at Cambridge University, and was originally written for the requirements of that institution and the University sector in general. However it has been used in many other sectors from the very early days - at one point the majority of UK ISPs were using Exim, and it may well still have a majority there. This means a lot of people depend on Exim - Universities to ISPs to those packaging operating system distributions.

Recent events - for example security vulnerabilities - show that we need to handle upgrades in a much more methodical and controlled way.

These people are basically those that have had involvement with Exim and have been interested in taking on development roles. The membership is by no means fixed, or closed, this is just what we are starting with.

There are some specific roles within the group, although at present they are not set in stone. For example I tend to mostly do infrastructure and chivvying work - although I can and do code where needed.

Since the vast majority of Exim users now obtain it via distributors such as Debian and Red Hat, we need to have some distributor/vendor involvement in the development process.

Sesame is a decent midrange server contributed by Cambridge University for Open Source development in general and Exim as a particular project.

At present it is managed by Tony Finch and myself

Source Code Control came late to Exim - in much the same way as the Linux kernel. CVS is the current vehicle although I guess a move to subversion could be possible.

The wiki has been under-used and under-publicised. I think I am going to push it a bit harder for the next 6 months, and then get a consensus if its worth the work it takes (which is admittedly not a lot after the initial setup and FAQ load.

There are a few issues on getting information out of the wiki (for example making a FAQ based on the wiki content) without significant re-keying or laborious cut and pasting

The Wiki is yet another target for those delightful people who think no medium is complete without a set advertisments for dubious services. Fortunately there are a number of anti-spam measures on the site, and up to now successful attacks have been very limited and very short lived.

Again Exim has done without a BTS for a long time. In general this has not been a problem, but with more people working the code - and with more people using it - we will need to have efficient shareable tracking of what needs doing, and what has been done. Bugzilla is being used because we have someone that understands it well and is prepared to set up and maintain the system.

The documentation is in SGCAL format at present (other formats are generated from that). The current intention is to move to using Asciidoc, which can be used to produce the appropriate output formats. Philip has started work on this conversion. The major reason for changing is so that we have a standard tool chain to produce documents - ie it does not have to be done on a machine in Cambridge which has SGCAL on it.

Philip has a sophisticated, but rather non-portable test rig for Exim where new versions are exercised before release. When problems are found the test rig is extended to attempt to cover previous problems and make sure that we do not regress.

This test rig needs to be replicated and made more generic. Exim is complex to test - a complete controlled network environment is needed (think about testing SMTP verification - which is affected by the connecting IP address, DNS issues (which change from minute to minute), timing etc etc). Current thoughts are along the lines of UML or Xen simulated networks.

I need to stress that at this point in the talk we are much further into the realms of my opinion, and decisions have not been made. So most of this section is my take on what needs doing, and should be used as the basis for argument.

I think we should always be ready to release a pure bug-fix release at short notice - for example if there is a security related bug discovered. For this reason I think that we should always branch development at every release, and put pure bug fixes into both branches, whilst putting new features and anything that requires configuration file or documentation updates only into the features branch. I am hoping that we do not require further formal development streams, although individual developers may take their own branches for "blue sky" work.

This will require changes to our version numbering - so we can always slot in a sudden bug fix release, and this needs to allow for development releases (ie alpha and beta releases) to have sensible version numbers as well.

As part of this working process we need to make sure we can tie changes together to the reasons for the changes - the bug report or feature request in Bugzilla. This may mean needing to enforce issue number referencing in commit messages.

We also really ought to make sure that code that gets into CVS compiles. At least for the most common configs (all platforms is asking a little much unfortunately).

Obviously if features are added we need to feed that into the documentation - even if initially that is just a placeholder for the documentation to be filled in fully later (don't necessarily expect or trust developers to be decent documentation writers).

Feature updates will also often require test suite updates. This needs to be thought about at the time we design and code the changes.

And finally this all has to be bought together into a release process - what do we need to do before we push code out the door.

This is all rather fluid at this time - I am talking to a number of people about how to do this. I am also in talks with an organisation about them taking on a co-ordination role for us, to help co-ordinate a security release to vendors etc.

By the time this talk is given I should have a much firmer idea of whats happening.

Exim is hard to package - but the vast majority of copies in use are using generic binary packages.

You have to decide on database support (and which ones) at compile time - and if you choose them all, you then have a package that pulls in all the database libraries as dependencies. This is the sort of thing hated by distribution makers - a package that suddenly requires a load of stuff thats not strictly necessary.