I'm very happy to report that Kurt Smith has been accepted for a Google Summer of Code project for working on Cython/Fortran integration!
http://wiki.cython.org/kwsmith/soc09 I'm his mentor for the project, and I start this thread to discuss how the GSoC should be arranged. (I suppose part of this could apply to the other accepted project as well: http://socghop.appspot.com/student_project/show/google/gsoc2009/python/t124024629578 ). The project is roughly going to be divided in two parts: (A) Use the f2py parser and output code for a Cython binding (B) Improve Cython in some areas (especially buffers) so that the bindings generated in a) can be much less messy and more convenient to use. Some things: 1) Where should the mentoring take place? Opinions on how much should happen on this list and how much should be done in private mail? Obviously language decisions etc. must end up here in the end, but what about day-to-day mentoring etc.? One possibility is setting up a seperate Google group just for this project, if it turns out that it would be too high traffic for the mailing list but other people would like to follow the project as well. 2) Code and patch workflow. On the (A) side, the status with f2py is that the author started a full rewrite (f2py 3G) which hasn't seen work for half a year (http://f2py.org/). So anything can happen here and we have to get back to how it's going to be done and where it should live. A relevant question though is whether we would like to ship the tool in (A) as part of Cython or have it as an independent download. (I don't expect it to add anything significant to download size, but Python core inclusion would be something to consider for or against here.) When it comes to (B), the obvious thing to do is for Kurt to pass the code to me for review and then merge it as often as we can with either -devel or -unstable (not sure which yet, possibly both). I'm wondering though whether perhaps Kurt could just get commit rights for the repos, under the strict understanding that he doesn't push anything which is not reviewed (for now at least). That could take some day-to-day merges off my back and make Kurt responsible for doing stable merges and think about the code integration schedule right from the start. We could then use e.g. codereview.appspot.com for doing the code reviews; I would then simply give thumbs up and Kurt would do the push. 3) Feedback There should be some kind of feedback mechanism; I expect to hear from Kurt at least weekly over the summer unless otherwise is arranged. I expect the ticket system will serve as the status update, and hope Kurt will make his progress visible through the ticket system (we can use the "fortran" tag on all GSoC related tickets for instance). I guess (A) would perhaps use a different tracker than (B), we need to get back to that. We could set something up at e.g. Google Code if the rest of the Cython team wouldn't like (A)-related tickets cluttering up the trac. We could use a seperate milestone though... Some mentors require students to keep a blog about what they are doing. Unless the Python Software Foundation makes this a requirement I'm going to leave this one up to Kurt; if the status is dutifully reported via tickets I'll have what I need personally, though a blog would be interesting as well. Dag Sverre _______________________________________________ Cython-dev mailing list [email protected] http://codespeak.net/mailman/listinfo/cython-dev
