On Apr 21, 2009, at 10:42 AM, Kurt Smith wrote: > 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?).
Yep, and it looks like both are going to be big steps forward in terms of usability. >>> 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. Day-to-day mentoring should probably be off-list, but I imagine the bulk of what goes on will be on-list. Maybe ask yourself if someone using the fortran-cython interface a year from now could possibly have any interest in reading the thread. >>> 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 ;) I brought the idea of a cython-users/cython-support list before, and there wasn't much interested. (Of course, those who couldn't handle the traffic of cython-devel never got the message...) If it's too specific to be on cython-devel, it probably make sense to have it just between Dag and Kurt. >>> 2) Code and patch workflow. >>> >>> 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. Lets not count on doing so for now at least. There are license considerations to consider too--f2py is GPL and as such wouldn't make it into Python without relicensing. >>> 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 think the best option is to have a new branch for this project. This at the very least will be a public, open place for people to look at and review the code. I anticipate it will get pulled into - devel or -unstable on a regular basis by Dag (and, depending on how things develop, hopefully Kurt will get push access too). >>> 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. If you're pushing to a public repo (see above) it will be relatively easy for us to pull your changes over (e.g. when you're ready, you pull from -unstable, merge, make sure all is well, and then when we've reviewed your stuff we pull your changes over to -unstable). > 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. Whatever works best for you two, that's what we should use. >>> 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? Thanks. Danilo, do you want to set one up for your project as well. - Robert _______________________________________________ Cython-dev mailing list [email protected] http://codespeak.net/mailman/listinfo/cython-dev
