[Evolution-maint] Permission for Evolution 2.8 transition

[Øystein Gisnås]

This is a request for approval from the release team to transition the
Evolution packages in unstable from version 2.6 to 2.8. There is a
transition planning status page at
http://folk.ntnu.no/oysteigi/evolution-transition-status.html

Evolution 2.8 was released September 4th along with its backend
Evolution Data Server, gtkhtml, Evolution Exchange, Evolution Webcal
and Evolution JESCS. The new versions contain some noticeable
improvements over 2.6. Some features such as three column display,
calendar drawn by cairo, considerably better performance, and better
stability make it worth upgrading. Some bugs popped up shortly after
the release, but these and other bugs have now been sorted out.

The new evolution-data-server brings 6 SONAME changes:
libebook1.2-[5->9], libecal1.2-[6->7], libedata-cal1.2-[5->6],
libedataserverui1.2-[6->8], libegroupwise1.2-[10->12],
libexchange-storage1.2-[1->2]. Note that all these changes are part of
the same source package. We've done our best to make sure there are no
other API/ABI breakage by inspecting all header changes and changes to
build scripts. Also, during almost two months since the release, no
other API/ABI breakage has been reported by other distros.

All reverse dependencies of the new packages have been inspected for
compatibility with the new version. 10 packages can safely be binNMUed
as long as they do not have a binNMU-incompatible control file. 6
packages need to be patched and rebuilt with patches that exist either
in upstream cvs/svn or bugzilla. I've personally rebuilt all packages,
tested (quick test of main functionality) the ones that can be tested,
and used 2.8 for several weeks.
http://folk.ntnu.no/oysteigi/evolution-transition-status.html shows an
overview of this.

The evolution packages have been sitting in experimental since October
4th, and have been used by a good number of users judging by the
amount of feedback and bug reports. Some rdepends have been built
against 2.8 and uploaded to experimental, and for the rest requiring
patches, upload have been request through a wishlist bug with a
pointer to the patch.

There are not yet any RC bugs that are fixed by 2.8 and not 2.6, but
upstream has stopped supporting 2.6. The benefits of a transition
therefore are:
*Security updates do not have to be backported from upstream
*Stability improvements (users have reported better IMAP stability)
*Performance improvements
*Demand for 2.8 among users

The release date of etch is not far away and a timely release of
Debian is of course more important than this transition. But if the
situation at any point suggest that there is enough time for the
transition, we have a team of four people to carry out a quick and
smooth transition whenever we are given the green light.

Cheers,
Øystein Gisnås
Debian Evolution Maintainer Team