Hi Thomas, Here's my feedback:
1. For any useful fixes you find here, please follow the normal procedures of raising a ticket and attaching a patch. In my experience, static analysis tools often carry with them a lot of irrelevant noise, but as long as the changes you propose are clean and don't break backwards compatibility, I would be happy to review and accept such changes. What I can't promise is that you will get much traction on trying to push a patch with a huge number of fixes at once. Every line of code we have to review increases the complexity of our job as reviewers. It would be great if you could break these up into small patches and would definitely increase the odds of the changes being accepted. We already have a reviewboard set up for zookeeper which you should plan to use, and of course the hadoop build farm. If you believe additional analysis tools would be useful in our build, please work with our build.xml and the infra team to get the necessary tools installed. It doesn't do us much good to fix things caught by your build server and then have them break again because we don't have the tooling available. 2. I doubt you will get much traction here on pushing changes back. I'm a big fan of refactoring but at some point refactoring for refactoring's sake does nothing but muddle the change history of a code base. Any refactoring that needs to be done would be best done in conjunction with a fix or feature that it helps to enable. 3. Sounds like a fun academic exercise for you. Maybe you could start with a Scala client that we could support. Not sure there's any benefit since Scala can run Java code, but it could be interesting and maybe something we could take back as a contribution if you wanted. C -----Original Message----- From: Thomas Koch [mailto:[email protected]] Sent: Friday, September 02, 2011 9:16 AM To: [email protected] Subject: ZooKeeper cleanup / refactoring / scala migration Hi, my university labs work has started yesterday. In the next two months I'll work on ZooKeeper. This work has three major goals - improve the maintainability of the code base - migrate ZooKeeper to scala and use actors for reliable concurrency - find other developers to collaborate on the scala version I plan to work in these steps: 1. use static analysis tools to cleanup the java codebase ( checkstyle, pmd, findbugs, eclipse compiler warnings ) 2. decrease dependencies in the ZK java packages, break cyclic dependencies 3. migrate components one-by-one to scala, starting with the leafs of the dependency graph I'd be happy if as much as possible of my work in steps 1. and 2. could also be useful for you. What would be a good strategy to go? I assume you're concentrating now on getting 3.4 out and don't have time for other things. Can I help on 3.4 blockers? I've set up a gerrit[1] (git based code review) and a jenkins[2] server for my project. Jenkins is armed with checkstyle, findbugs, pmd, copy-paste-detection and jdepends. I've carefully selected the checks run by checkstyle and pmd and would suggest that the remaining warnings should really be eliminated. Gerrit already hosts two changesets which eliminate nearly all eclipse compiler warnings. I'd be happy if you'd like to create an account at the gerrit instance (openid needed) and play around with it. I can also give you reviewer status which lets you push changes. Every change push will trigger a jenkins build. I've already proposed to [email protected] that I'd help in setting up a gerrit server for the ASF if any project would be interested. [1] http://koch.ro:8081 [2] http://koch.ro:8080 Best regards, Thomas Koch, http://www.koch.ro
