答复：[DISCUSS] Plan for Merging JStorm Code

["瑾涵(王桐Wang Tong)" <wa...@alibaba-inc.com>]

sure, I can do the 
performance test, do we have any 
performance test cases ?------------------------------------------------------------------发件人：Cody Innowhere <e....@gmail.com>发送时间：2015年11月11日(星期三) 15:04收件人：dev <de...@storm.apache.org>主　题：Re: [DISCUSS] Plan for Merging JStorm Code
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 <su...@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" <ma...@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)
>
>