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
