Hi Basti, Seems like Phase 3.1 covers Phase 2.2 since Phase 3.1 is actual work for Phase 2.2. So in Phase 3.1, if JStorm code is fully compatible, we can just pick it. If JStorm code is not compatible, we can port Clojure code, or implement it based on JStorm code. If you were talking about baseline, please read my opinion on phase 3.
All, For phase 1, I'm also +1 for releasing 0.11.0 as 1.0.0. Apache Storm already has various use cases, which feels me no longer beta. For phase 3, I'm +1 for what Taylor suggests. Precondition of my opinion is that we agree that our merged product will be named as 'Apache Storm'. Based on this decision, we may want to set baseline to Apache Storm, cause users expect features based backward compatibility to newer releases. (Brand and community is most important thing for open source product, and our moves should avoid hurting them. Losing users lose all.) Many features are included via 0.10.x and 0.11.0 (master branch), which means Apache Storm and JStorm is diverged. 'Core' is no except. Not fast but safest is, keeping Apache Storm as it is (or port Clojure code to Java, as we start to discuss), and applying JStorm's amazing features via pull requests, like normal contributions. I love this approach since it is more natural. Thanks, Jungtaek Lim (HeartSaVioR) 2015-11-11 20:41 GMT+09:00 刘键(Basti Liu) <basti...@alibaba-inc.com>: > Hi Taylor, > > > > Thanks for the merge plan. I have a question about “Phase 2.2”. > > Do you mean community plan to create a fresh new “java core” based on > current “clojure core” firstly, and then migrate the features from JStorm? > > If so, it confused me. It is really a huge job which might require a long > developing time to make it stable, while JStorm is already a stable version. > > The release planned to be release after Nov 11th has already run online > stably several month in Alibaba. > > Besides this, there are many valuable internal requirements in Alibaba, > the fast evolution of JStorm is forseeable in next few months. > > If the “java core” is totally fresh new, it might bring many problems for > the coming merge. > > So, from the point of this view, I think it is much better and easier to > migrate the features of “clojure core” basing on JStorm for the “java core”. > > Please correct me, if any misunderstanding. > > > > Regards > > Basti > > > > 发件人: P. Taylor Goetz [mailto:ptgo...@gmail.com] > 发送时间: 2015年11月11日 5:32 > 收件人: dev@storm.apache.org > 主题: [DISCUSS] Plan for Merging JStorm Code > > > > Based on a number of discussions regarding merging the JStorm code, I’ve > tried to distill the ideas presented and inserted some of my own. The > result is below. > > > > I’ve divided the plan into three phases, though they are not necessarily > sequential — obviously some tasks can take place in parallel. > > > > None of this is set in stone, just presented for discussion. Any and all > comments are welcome. > > > > ------- > > > > Phase 1 - Plan for 0.11.x Release > > 1. Determine feature set for 0.11.x and publish to wiki [1]. > > 2. Announce feature-freeze for 0.11.x > > 3. Create 0.11.x branch from master (Phase 2.4 can begin.) > > 4. Release 0.11.0 (or whatever version # we want to use) > > 5. Bug fixes and subsequent releases from 0.11.x-branch > > > > > > Phase 2 - Prepare for Merge ("master" and "jstorm-import" branches) > > 1. Determine/document unique features in JStorm (e.g. classpath isolation, > cgroups, etc.) and create JIRA for migrating the feature. > > 2. Create JIRA for migrating each clojure component (or logical group of > components) to Java. Assumes tests will be ported as well. > > 3. Discuss/establish style guide for Java coding conventions. Consider > using Oracle’s or Google’s Java conventions as a base — they are both > pretty solid. > > 4. align package names (e.g backtype.storm --> org.apache.storm / > com.alibaba.jstorm --> org.apache.storm) (Phase 3 can begin) > > > > > > Phase 3 - Migrate Clojure --> Java > > 1. Port code/tests to Java, leveraging existing JStorm code wherever > possible (core functionality only, features distinct to JStorm migrated > separately). > > 2. Port JStorm-specific features. > > 3. Begin releasing preview/beta versions. > > 4. Code cleanup (across the board) and refactoring using established > coding conventions, and leveraging PMD/Checkstyle reports for reference. > (Note: good oportunity for new contributors.) > > 5. Release 0.12.0 (or whatever version # we want to use) and lift feature > freeze. > > > > > > Notes: > > We should consider bumping up to version 1.0 sometime soon and then > switching to semantic versioning [3] from then on. > > > > > > With the exception of package name alignment, the "jstorm-import" branch > will largely be read-only throughout the process. > > > > During migration, it's probably easiest to operate with two local clones > of the Apache Storm repo: one for working (i.e. checked out to working > branch) and one for reference/copying (i.e. checked out to "jstorm-import"). > > > > Feature-freeze probably only needs to be enforced against core > functionality. Components under "external" can likely be exempt, but we > should figure out a process for accepting and releasing new features during > the migration. > > > > Performance testing should be continuous throughout the process. Since we > don't really have ASF infrastructure for performance testing, we will need > a volunteer(s) to host and run the performance tests. Performance test > results can be posted to the wiki [2]. It would probably be a good idea to > establish a baseline with the 0.10.0 release. > > > > I’ve attached an analysis document Sean Zhong put together a while back to > the JStorm merge JIRA [4]. The analysis was against the 0.9.3 release but > is still relevant and has a lot of good information. > > > > > > [1] > https://cwiki.apache.org/confluence/display/STORM/Release+0.11.0+Feature+Set > > [2] https://cwiki.apache.org/confluence/display/STORM/Storm+Home > > [3] http://semver.org > > [4] https://issues.apache.org/jira/browse/STORM-717 > > > > > > -Taylor > > > > -- Name : 임 정택 Blog : http://www.heartsavior.net / http://dev.heartsavior.net Twitter : http://twitter.com/heartsavior LinkedIn : http://www.linkedin.com/in/heartsavior
