Hey Thomas! I've raised a scala port a number of times previously, most recently at the post-summit meetup: http://markmail.org/message/t32x22hmifo3urxk We discussed this shortly both at the meetup and subsequently on list. Unfortunately there was no consensus around building ZK on scala (or any other language other than java -- Ted asked to port to clojure instead), in particular the point was raised that we, the currently zk community, are a community of ZK Java developers with no experience with scala (or clojure/c#(?) for that matter).
What I think would be successful is for you to bring this to the incubator - "ZooKeeper-Scala: re-implement ZooKeeper in Scala". A community of ZK scala developers could be grown there, see the proposal guide, in particular we (ZK tlp) could sponsor this effort, with the intent that upon successful graduation from the incubator we pull in zk-scala as either a subproject or just part of the TLP but as a separate release artifact from zk java server. see this link for details: http://incubator.apache.org/guides/proposal.html#template-sponsoring-entity I'd be willing to be the champion and a mentor for this project in the incubator. Regards, Patrick On Fri, Sep 2, 2011 at 7:12 AM, Fournier, Camille F. <[email protected]> wrote: > 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 >
