From: William S F. <ws...@fu...> - 2008-07-02 22:35:33
|
Richard Boulton wrote: > Haoyu has now got his python 3 branch to a point where it can generate > code which works well with python 3.0, to the extent that a fairly > complex library (xapian) can be imported and used from python3. > > He still has several further parts of his project to work on, but I > thought this would be a good time to think about how to go about merging > his code into trunk. > Great, this might be a first for GSoC! Releasing the student's code into trunk is sometimes not even done after the GSoC project has completed, never mind midway through. > There are some parts of the code which are probably uncontroversial for > merging: for example, converting exception raising code from "raise > FooError, e" to "raise FooError(e)" (since there are already instances > of the latter construct in the generated code, so there are no > compatibility issues). > > However, other bits will need discussion - for example, there's a lot of > conditional compilation in the new code, which could do with being > tidied up. > > One question I was wondering about: should we try and use some system > for doing online code reviews - there's an application at > http://codereview.appspot.com/ which allows any project to register, and > is being used for python development, and quite a few other projects, so > might be worth a look. There's also a rather nice application called > "review board" (http://www.review-board.org/) which might be better - > this one is from the VMWare people, and seems very flash - but we'd need > to find somewhere to install it, and it doesn't sound like a trivial > install. > Whichever you think is easiest. Ultimately we need an easy way to view the patches visually. If appspot is easy to set up, we could try that, I'm always interested in trying out new inventive tools and it sounds like one. > The hope is that such a system would enable us to keep track of which > parts of the code have been reviewed and approved. But perhaps just > doing this manually, with email and the patch tracker, would be better. > Thoughts? > Those tools sound like they are worth a try. > My feeling is that getting started with the process of merging sooner > rather than later is a good plan - the requirement should be that > changes going to trunk should have been reviewed by at least one > experienced SWIG developer, and that trunk should remain in a working > state at all times. > I can help review, but won't necessarily have much input on the Python aspects. > Haoyu's going to be busy with exams for the next week and a bit, so this > isn't urgent, and we have time to work out what the best procedure for > merging changes from the GSOC branches to HEAD would be. > William |