I wonder, is it possible to separate the ZooKeeper part of the code to make things easier to review?
~Haohui On Wed, Jan 13, 2016 at 6:39 AM, Bobby Evans <ev...@yahoo-inc.com.invalid> wrote: > That is great to hear. We will work on getting your dependencies put in > place ASAP. > - Bobby > > On Wednesday, January 13, 2016 6:03 AM, 刘键(Basti Liu) > <basti...@alibaba-inc.com> wrote: > > > Hi Bobby, > > For dependencies, we have not done much work on these modules except the ones > related to zookeeper (cluster.clj and zookeeper.clj). > When doing the migration of Nimbus and Supervisor, we just updated the name > of relative functions called in Nimbus and Supervisor by the > guidelines you gave below, and left empty implementation for these in > relative modules. > So, please feel free to start on utils.clj and config.clj. > > Following is the detailed status for Nimbus, Supervisor and zookeeper modules > currently. We will also update the status in JIRAs. > - Nimbus: 30% The structure of state transition and service handler are > almost done. Blob store, replication between Nimbus and security have not > been started yet. > - Supervisor: 90% Only health check was left. > - Zookeeper: 40% Most interfaces of reading operation have been done. > > Regards > Basti > > -----Original Message----- > From: Bobby Evans [mailto:ev...@yahoo-inc.com.INVALID] > Sent: Tuesday, January 12, 2016 10:35 PM > To: 刘键(Basti Liu); dev@storm.apache.org > Subject: Re: 1.x storm and jstorm merger > > For the migration of fixes, we have the policy that fixes need to go into > master before they can be merged into previous branches, so with that the fix > would go into master and anyone who wants the fix on an older branch would be > responsible for porting it to clojure. > It is great to hear that there is progress being made on Nimbus and the > Supervisor, but those are very large pieces of code with lots of > dependencies. I would really like to sync up with you and what you are doing > so we don't get too much duplicated efforts. Specifically my team is > starting on utils.clj and config.clj. But if you have already done some/all > of the work for them I would rather use that work instead. I also want to > check changes in frequently with smaller differences. Less differences means > we should be able to find bug sooner and adjust accordingly. Is there any > way you could take some of what you have done, even if it is not complete and > put up pull requests for the portions that do work and can be swapped out? > Particularly in underlying files. Or at least put it in a place that we can > look at it? > - Bobby > > On Monday, January 11, 2016 9:31 PM, 刘键(Basti Liu) > <basti...@alibaba-inc.com> wrote: > > > Hi Bobby, > > It is great to see that we are going to finalize Storm 1.x and start the > migration. > Just to synchronize current status of migration in Alibaba, the migration of > Nimbus and Supervisor part is in progress(around 50% is completed). > Besides it, we'd like to confirm the handling of following bug fixes in > branch-1.x. Who is responsible to migrate the fix from branch-1.x to mater > branch(2.0.0-snapshot)? the owner of the JIRA in branch-1.x or the owner of > corresponding migration JIRA in master branch? > > Regards > Basti > > -----Original Message----- > From: Bobby Evans [mailto:ev...@yahoo-inc.com.INVALID] > Sent: Tuesday, January 12, 2016 5:39 AM > To: Dev > Subject: 1.x storm and jstorm merger > > I think we are finally at the point were this is going to start happening. > I have merged in as many JIRA/PULL requests that looked like they were ready. > The most disruptive of these is probably STORM-1202, which translated > backtype.storm to org.apache.storm and storm.trident to > org.apache.storm.trident There is some hack code that we will remove in the > future that when submitting a topology using the new client it will translate > your jar for you to the new namespaces. You can enable it by setting > `client.jartransformer.class` to `org.apache.storm.hack.StormShadeTransformer` > > With that I changed the 0.11.0 tag to 1.0.0. And I created a branch-1.x > branch in the main repo. I have not started creating a release candidate > just yet as there still are a few outstanding bugs that I would like to see > resolved before hand. > https://issues.apache.org/jira/issues/?jql=project%20%3D%20STORM%20AND%20type%20%3D%20Bug%20and%20resolution%20%3D%20Unresolved%20and%20priority%20%3E%3D%20Blocker > > Of them only STORM-1452 really feels like a blocker, but I am open to others > opinions as we work towards a release. I would encourage everyone to kick > the tires on it and file JIRA if you do find any issues. > > > > I also changed the version on master to 2.0.0-SNAPSHOT in preparation for the > migration to java and the JStorm merger. This means that we are now open to > start pulling in java migration pull requests as outlined on the wiki > https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=61328109 > I know that my team is going to start working on this process now to try and > shorten the time of the transition as much as possible. From this point on > until the transition to java is complete there will be a moratorium on new > features going into storm. This is not a hard moratorium. If your changes > only touch java code, like in the external projects, etc. I don't think > anyone will complain if new features go in, but this is mostly to reduce > churn in the code so the transition is a smooth as possible. To help with > this, and because there was some discussion about style guidelines, etc I > through together a wiki for some conventions/guidelines. > > https://cwiki.apache.org/confluence/display/STORM/Java+Migration+Guidelines > I put it together mostly to have a place for it. I am not religious about > the guidelines, I just want us to have some as we go forward, and I don't > really want to wait for someone to reformat all of the files and put checks > in place for them. If others disagree we can modify them as we see fit. > As far as coordination in doing the translation I will try to update the > JIRAs that I filed to match what is currently out on master. When you do > pick up a JIRA to work on please assign it to yourself and move the state to > "In Progress" so everyone knows that you are working on it. If you want to > pick up something but it depends on something someone else is doing and it is > not being completed in a timely manor, please comment on the JIRA before > doing anything to ask for a status update. If they are unable to respond > within a few days feel free to take over the JIRA. I personally thing moving > quickly is more important than hurt feelings. So please pay attention to > comments on the JIRA you are working on. - Bobby > > > > > >
