Thanks Taylor. The plan looks good.
> 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"). Do you mean two storm branches(both clojure core) or one storm branch with one JStorm-imported branch? Tong.Wang is responsible for integration tests of JStorm, @Tong.Wang, could you see to it if you can do the performace test? On Wed, Nov 11, 2015 at 8:00 AM, Suresh Srinivas <sur...@hortonworks.com> wrote: > +1 for 1.0.0 release. > > I also like Hackathon to encourage bigger participation. It will be fun. > > On 11/10/15, 3:38 PM, "Harsha" <m...@harsha.io> wrote: > > >Thanks Taylor for putting together plan on merging JStorm code. > >Few things > > > >1. we should call 0.11.0 as 1.0.0 release since storm has security and > > nimbus ha . Quite a lot of features and improvements added this is > > going to be big release and its about time we call 1.0.0 > > > >1.1 "align package names (e.g backtype.storm --> org.apache.storm / > >com.alibaba.jstorm --> org.apache.storm) (Phase 3 can begin" I > >propose we do this as next release itself instead of pushing it > >onto another . > > > >"Phase 3 - Migrate Clojure --> Java" > > > >I would like to propose a Hackathon among storm community along with > >jstorm. We need to come up with plan of action on what code needs to be > >merged into storm-core. I am thinking it will help better to have > >everyone over video chat or something to go over the code and get it > >migrated to java. > > > > > >Thanks, Harsha > > > >On Tue, Nov 10, 2015, at 01:32 PM, P. Taylor Goetz wrote: > >> 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 > >> > >> Email had 1 attachment: > > > > > >> * signature.asc 1k (application/pgp-signature) > >