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
<https://cwiki.apache.org/confluence/display/STORM/Storm+Home>
[3] http://semver.org
[4] https://issues.apache.org/jira/browse/STORM-717
-Taylor
signature.asc
Description: Message signed with OpenPGP using GPGMail
