+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)
