I emailed upstream about a year ago (
http://sundials.2283335.n4.nabble.com/Packaging-sundials-for-debian-td4653658.html), and I sent them the patches directly, but never heard back from them. I've got no idea about upstream's release schedule or future plans, the 2.7 release came as a complete surprise to me. I get the impression sundialsTB may be gone for a while (as while it hasn't changed for 7 years, I don't see much change in the higher level interface of sundials, apart from the new runga-kutta solver, which sundialsTB doesn't support, so maybe there's bugs which haven't been mentioned on the mailing list?), but that just speculation, and they could just as well be working on a 2.7.1 release which only updated sundialsTB.
I ignored the tests, I've had no problems building scikits.odes on top of sundials, and I'm not inclined to trust examples where results may vary based on optimisation, as opposed to real tests (this could be something worth asking upstream about).
What's your plan on the organisation of the packages, my idea (which I haven't started on, I'm very open to opinions on this) was to have a package per DSO (which makes more sense if we add support for the other parallelisation method sundials now has), a libsundials-dev which has the things for each of the solvers, but not the serial/parallel/openmp stuff, and which depends on a separate libsundials-{serial/parallel/openmp/etc.}-dev? I can also see advantages for splitting out separate packages for each of the solvers, or for a single dev package, but I thought that this would involve the least change. OTOH, there's nothing in Debian which depends on sundials, and it's isn't that popular, so that may not be a strong argument.