Ideas for my Proposal: RBTools Improvements

19 views
Skip to first unread message

Steven MacLeod

unread,
Apr 1, 2012, 9:08:14 PM4/1/12
to reviewbo...@googlegroups.com
I'm interested in the RBTools improvement projects, and have been working on my proposal for GSoC. I've been discussing some of the work that needs to be done with Christian, and it appears there are 3 main areas that require attention:

 1. A formal API intended for third-party usage in rbtools.api. This would provide all the server communication, and would be documented.

 2. Have a cleaner set of classes for each SCMClient in rbtools.clients. These should be usable by third parties as well, and it should be more clear what each function's purpose is. This should also allow for third-parties to provide custom SCMClients as part of their own Python packages (using the setuptools entrypoints system)

 3. Provide a new "rb" script that works like "git", in that it's pluggable. There would be many utility functions for common things for the server. Updating review requests/diffs, closing them, listing data, etc. This would eventually entirely replace post-review

 It appears that a former student is currently working on code for [1], which he has indicated should have a code drop soon. Here are a few of my ideas, which focus on [3]:

 - Much of the code present in the RBTools api branch for [3] appears to be undocumented and broken. I would like to get a better idea of which commands should be implemented and better document the interface. I'd plan to clean up the current code, and implement a system for documenting the commands in or near the actual code.

 - The code for [3] requires proper logging and error handling. Standardizing the way errors and output are handled will be necessary. This includes removing many of the current print statements.

 - [3] should be using [1]. I'd like to work towards making this happen. This new code will be helpful in testing the new API, and I can help out with completing [1] along the way.

 - Currently each command in [3] is a separate script which the main rb script executes. Might it be better to have a system where the main rb script will preform a number of common operations, such as initializing the environment to communicate with the Review Board server? It might be beneficial to implement the commands using the setuptools entrypoints system; this also makes it easy for third parties to extend RB tools.

Do these modifications seem reasonable?

Another interesting project Christian mentioned was working to make [1] asynchronous. This involves implementing something similar to http://www.tornadoweb.org/documentation/gen.html that the API can use. It would be fun to work on this, but it would depend on how much work towards this is present in the upcoming code for [1].

Thanks,

Steve
Reply all
Reply to author
Forward
0 new messages