Hi Stefan,
Your schedule above looks very ambitious, and, I fear, quite unrealistic:
You're right about the timeline: it is too ambitiuos. Though some work it is already done and it only needs polishing. Anyways I'll make it shorter, maybe by scrapping out the multi-threading part for post-GSOC work.
For that reason, as well as for reasons I already outlined in a previous post, I strongly suggest you change the ordering (and timing) of your milestones, to first focus on an API that can be implemented as a wrapper around FFTW (as I suspect that will be the implementation most developers will use until you have an alternative that actually out-performs FFTW), and only then start to re-implement your API with other backends (including your own).
Wrapping FFTW is not a priority I have. I believe that the right way to work towards an FFTW/C++ api will be to do so directly into the FFTW project. Sooner or later someone will do it. What I want to bring to Boost.Math are "Generic Programming" FFT algorithms for situations that FFTW can't handle. And I want them to have decent performance for complex numbers, I do not aim to outperform FFTW. With time it can be improved and one day it will become competitive with FFTW. In part, the success of the FFTW is due to the "codelets", which are functions for small and fixed-size FFTs that they generate from a C code that is generated by a program called "genfft". I believe we can do better with C++ compile-time programming. Not for this summer though... Thanks for the feedback. Eduardo