I'm not necessarily endorcing this idea, but if 0.9.1 is planned for a somewhat distant release (~months), people may become more comfortable with Netty during that time, as it's already included in the current release (and will be "less shiny/new" by the time 0.9.1 is released).
With the plugable transport mechanism, could JZMQ be spun off into a separate non-Apache github or such, and then people just pull that down if they want to use that layer? I believe this is done for some other components already. On Fri, Dec 6, 2013 at 1:55 PM, P. Taylor Goetz <[email protected]> wrote: > (changing subject to better describe the topic — was "[DISCUSS] Time to > release 0.9.0?") > > Thanks for the clarification Matt. > > I’m not sure why that decision was made. In at least one case I believe > there was a source code change in order to make the library work with storm > (off the top of my head I forget which one). > > Going forward I would like to use all versioned releases if possible. I > think it’s just a matter of testing to determine the right versions. > > The other concern I have is our dependency on JZMQ which has an LGPL > license. The JZMQ library is required if using the 0mq transport, but not > required if the Netty transport is used. > > My understanding is that we would be okay with a source only release > (since it wouldn’t include the JZMQ jar), but for a binary release we would > have to explicitly exclude the JZMQ jar since Apache releases cannot > contain LGPL-licensed works. > > Am I correct? Or would we have to entirely eliminate 0mq/JZMQ as a > dependency? > > We’re kind of okay if it is the latter, since we have an alternative to > the 0mq transport. But the Netty transport is young compared to the 0mq > transport, and some folks might not be comfortable with it until it has > seen more productions time. > > - Taylor > > > On Dec 6, 2013, at 10:23 AM, Matt Franklin <[email protected]> > wrote: > > > In general, maintaining custom forks gets tough after a while (as I am > sure > > you are aware). Technically speaking, so long as their code is released > > under a compatible license, we redistribute our changes as source and > > correctly add LICENSE and NOTICE entries it should be OK. > > > > Do none of these release dependencies have releases that can be > > downloaded/included during build time? If so, that greatly simplifies > our > > source release. Was there a reason you went for point-in-time forks > > instead of versioned releases? > > > > > > On Wed, Dec 4, 2013 at 2:16 PM, P. Taylor Goetz <[email protected]> > wrote: > > > >> Thanks Matt that helps a lot. > >> > >> We anticipated delays in the first Apache release, hence the desire to > get > >> a non-Apache 0.9.0 release out to our community before that move (the > >> community has been waiting for 0.9.0 for a long time). > >> > >> We’ve already started/completed a number of items in the list. > >> > >> One issue that might be the biggest wrinkle has to do with the fact that > >> some of Storm’s dependencies are forks of other projects. > >> > >> For example, if you look at the project file for storm-core [1] you will > >> see a few dependencies with the “storm” groupId: > >> > >> 1. storm/libthrift7 — This is (AFAIK) a point-in-time fork of Apache > >> Thrift. The only modification was to change the package names. Impetus > >> behind this is discussed here [2]. The source repository *appears* to be > >> here [3]. > >> > >> 2. backtype/jzmq — Looks like just a point-in-time fork. [4] > >> > >> 3. storm/carbonite [5] — Looks like the modifications here are just to > >> pull in a different version [6] of kryo as a transient dependency. I > can’t > >> seem to find the source for the storm/kryo dependency. > >> > >> 4. storm/jgrapht — I can’t find the source for this. I believe it’s > just a > >> repackaging of the main jgrapht code [7]. > >> > >> > >> We should be able to get 0.9.0 released out of github soon. We’re > waiting > >> on one final issue to be resolved [8]. > >> > >> It may make sense to make the first release from Apache with the 0.9.0 > >> code with the above issues sorted out — essentially no code changes > aside > >> from license headers, dependency updates, etc. For the Thrift > dependency, > >> we might be able to use jarjar [9] to simply repackage an Apache > release. > >> > >> I’m open to suggestions. > >> > >> - Taylor > >> > >> > >> [1] > https://github.com/nathanmarz/storm/blob/master/storm-core/project.clj > >> [2] > >> > https://groups.google.com/forum/#!searchin/storm-user/thrift$20cassandra/storm-user/evK3M--3QaI/CP2EQDLnxqkJ > >> [3] https://github.com/nathanmarz/thrift-dev > >> [4] https://github.com/nathanmarz/jzmq > >> [5] https://github.com/nathanmarz/carbonite > >> [6] https://github.com/nathanmarz/kryo > >> [7] https://github.com/jgrapht/jgrapht > >> [8] https://github.com/nathanmarz/storm/pull/726 > >> [9] https://code.google.com/p/jarjar/ > >> > >> > >> > >> > >> > >> On Dec 4, 2013, at 6:21 AM, Matt Franklin <[email protected]> > >> wrote: > >> > >> Glad to hear that we are going for the Apache release. Releasing at > Apache > >> requires a bit more work than you are used to and it will take more time > >> than everyone would like for the first time. Good news is that I and > the > >> other mentors are here to help you through the process. > >> > >> To get started we will need: > >> > >> 1) To make sure code is in the official apache git repo > >> 2) We have gone through the code and done LICENSE & NOTICE creations > [1-2] > >> 3) We have asked INFRA to setup svn-pub-sub for our releases > >> 4) We have requested Nexus access for the PPMC members > >> 5) The release manager(s) have their release keys in the Apache web of > >> trust [3] > >> 6) We create release process documentation for the project [4-5] > >> > >> Here is some starting info that everyone should read: > >> > >> [1] http://incubator.apache.org/guides/releasemanagement.html > >> [2] http://www.apache.org/dev/release.html > >> [3] http://www.apache.org/dev/release-signing > >> [4] http://camel.apache.org/release-guide.html > >> [5] http://rave.apache.org/release-management.html > >> > >> > >> On Wed, Nov 27, 2013 at 6:20 PM, P. Taylor Goetz <[email protected]> > >> wrote: > >> > >> Awesome. I'm looking forward to getting 0.9.0 out. > >> > >> BTW, I have a trivial pull request open (#759) that I'd like to merge, > but > >> it's not a big deal. > >> > >> - Taylor > >> > >> On Nov 27, 2013, at 5:56 PM, Nathan Marz <[email protected]> wrote: > >> > >> I agree, it's time to release and get moving with completing the > >> > >> migration > >> > >> to Apache. Once those issues are merged let's do a release. > >> > >> > >> On Wed, Nov 27, 2013 at 8:38 AM, Bobby Evans <[email protected]> > >> > >> wrote: > >> > >> > >> I have done a bit of CI work in apache for hadoop before and I still > >> > >> have > >> > >> power to set up new builds/etc on builds.apache.org, so I am happy to > >> volunteer my services once the repository is migrated to apache. I am > >> > >> not > >> > >> sure how fancy we want to get with pre commit builds etc. a lot of that > >> probably depends on how we plan on doing issue tracking/submitting pull > >> requests. > >> > >> --Bobby > >> > >> On 11/26/13 11:37 PM, "P. Taylor Goetz" <[email protected]> wrote: > >> > >> Agreed. > >> > >> I think one of the top priorities will be to work with Apache INFRA to > >> get some sort of CI environment set up. > >> > >> - Taylor > >> > >> On Nov 27, 2013, at 12:19 AM, James Xu <[email protected]> wrote: > >> > >> I agree it’s time to release and the unit test should pass before > >> release. (I just released that we don’t have Travis CI like many other > >> open source projects have). > >> > >> On 2013年11月27日, at 下午1:15, P. Taylor Goetz <[email protected]> > >> > >> wrote: > >> > >> > >> It’s been over two months since Storm has entered the Apache > >> > >> incubator. > >> > >> > >> I think it’s time to release 0.9.0 and move forward with adopting the > >> Apache process for releasing, getting IP clearance, etc. > >> > >> I’ve not seen much feedback from the community on the release > >> candidates, but from what I’ve seen 0.9.0-rc3 is pretty solid. > >> > >> That being said, there are two remaining issues that I think should > >> > >> be > >> > >> addressed: > >> > >> 1. https://github.com/nathanmarz/storm/pull/726 > >> > >> I’ve not seen this reproduced, but I think it is valid and should be > >> addressed (see my comments in the pull request). I’m okay if we just > >> eliminate the possibility for negative sleep values for now. We can > >> change the implementation later to back off in a predictable way. > >> > >> 2. https://github.com/nathanmarz/storm/pull/755 > >> > >> This is arguably cosmetic, but I feel unit tests should pass for any > >> release. (I’d also like to change the release script so it fails if > >> > >> any > >> > >> unit tests don’t pass ― I can create an issue for that, and take on > >> > >> the > >> > >> work). > >> > >> I’m open to suggestions to any other pull requests/issues that anyone > >> feels should be included. > >> > >> If there are any critical bugs discovered in 0.9.0, we can always > >> release a bug fix release (e.g. 0.9.0.x) outside of Apache. > >> > >> In a nutshell, I think we need to decide whether we want to fish or > >> cut bait in terms of the move to Apache. I don’t want to see Storm > >> stagnate in the incubator. > >> > >> I look forward to hearing others’ thoughts on the matter. > >> > >> - Taylor > >> > >> > >> > >> -- > >> Twitter: @nathanmarz > >> http://nathanmarz.com > >> > >> > >> > >> > >
