On Tue, Apr 21, 2009 at 12:01 PM, Stefan Behnel <[email protected]> wrote: > Dag Sverre Seljebotn wrote: >> 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! > > Yep, congrats!
Thanks! And thanks to you, Robert, Dag and everyone else for accepting the project. I'm pleased to see that Cython has 2 GSoC projects this year, too (one more than last year?). >> 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.? > > Depends. Trivial/basic things may go into private mail, but I would prefer > having most of the discussions on the list, where others can > help/find/learn, too. This is an open source project, so things should > happen in the open. I'm with you there -- we'll get a feel as time goes on, but by default the substantial threads would be on the list. > > >> 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. > > Let's see about that when we notice that it gets too much traffic. > > I would lean more towards a separate cython-users list than a separate > sub-dev list. (I have ignored threads before, so I know I'll cope ;) > > >> 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. > > Sounds like the right thing to ask the author first. Dag just sent off an email to Pearu this morning outlining our approach and possible options. We'll let you know the results & cc the list if need be. > > >> 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.) > > Let's decide that when we can take a look at it. > > >> 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). > > Definitely not the current cython-devel, but without further detail (that > may become available once the project has left the initial planning > phase), I can't tell if it makes more sense to add another branch. Given > the time-frame of the GSoC, maybe even cython-unstable is too close to > release to add major new, unfinished features. Parts may go in earlier, > obviously, so a branch from which we can import stuff may make sense. > > IMHO, too early to decide. I/we should have a better grasp on this in a couple of weeks at most. > > >> 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. > > I wouldn't mind giving him write access, though I don't see an immediate > need for that. Patches will require reviews anyway, even major design > reviews. I have no great eagerness for write access, and I'll need to prove trustworthiness to get there. I hope that at a future date after patches are reviewed and committed by yourselves it'll make more sense to grant me write access, with the understanding that I'll put up the patches for review first. Honestly, my mercurial-fu isn't marvelous at the moment (I can do the basic things and am establishing my workflow, but if I were to mess something up I'd need help fixing it) and I'd like some more experience in the day-to-day work before being given access to something that matters. > > >> 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. > > Looks like they didn't fix the login issue yet. It still requires a Google > account to comment. > > >> 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). > > Sure. Please take care to cut down the subject of tickets to make sure it > has a provable result. Otherwise, it's not clear when the ticket is > solved. > > It's fine to have a couple of tickets that depend on each other. Sounds fine to me. >> I guess (A) would perhaps use a different tracker than (B), we need to >> get back to that. > > Why? As long as we consider integrating it with Cython, I'm fine with > tracking the required work here. > > >> 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. > > It would be nice, yes. I'll get one set up. Any canonical place for GSoC blogs that anyone knows of? Kurt _______________________________________________ Cython-dev mailing list [email protected] http://codespeak.net/mailman/listinfo/cython-dev
