You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@storm.apache.org by "P. Taylor Goetz" <pt...@gmail.com> on 2013/11/27 06:15:22 UTC
[DISCUSS] Time to release 0.9.0?
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
Re: [LEGAL] Storm Project Dependencies
Posted by Brian O'Neill <bo...@alumni.brown.edu>.
Done:
https://issues.apache.org/jira/browse/STORM-1
-brian
---
Brian O'Neill
Chief Architect
Health Market Science
The Science of Better Results
2700 Horizon Drive • King of Prussia, PA • 19406
M: 215.588.6024 • @boneill42 <http://www.twitter.com/boneill42> •
healthmarketscience.com
This information transmitted in this email message is for the intended
recipient only and may contain confidential and/or privileged material. If
you received this email in error and are not the intended recipient, or
the person responsible to deliver it to the intended recipient, please
contact the sender at the email above and delete this email and any
attachments and destroy any copies thereof. Any review, retransmission,
dissemination, copying or other use of, or taking any action in reliance
upon, this information by persons or entities other than the intended
recipient is strictly prohibited.
On 12/6/13, 2:51 PM, "P. Taylor Goetz" <pt...@gmail.com> wrote:
>I think how we handle it depends on the answer to the LGPL dependency
>question.
>
>If 0mq/JZMQ has to be ripped out, it will be extracted and moved outside
>Apache so we can release.
>
>If it can stay, then I’d like to see it move to its own module alongside
>the storm-netty module. That would also make it easier to modify the
>build process so users can build only the modules they want/need (default
>would be all modules).
>
>When/if that happens depends on an answer to the license question, and
>the level of effort required to extract the 0mq transport to it’s own
>module.
>
>I’m not aware of a JIRA for it, but one can be submitted here [1] (I
>can’t access JIRA at the moment).
>
>[1] https://issues.apache.org/jira/browse/STORM
>
>On Dec 6, 2013, at 11:06 AM, Brian O'Neill <bo...@alumni.brown.edu> wrote:
>
>>
>> Minimally (and not sure if it suffices for legal reqs), Storm should be
>> able to build without JZMQ. (ASAP, IMHO =)
>>
>> Has that been taken care of already? (is there an issue created for
>>that?)
>>
>> -brian
>>
>> ---
>> Brian O'Neill
>> Chief Architect
>> Health Market Science
>> The Science of Better Results
>> 2700 Horizon Drive • King of Prussia, PA • 19406
>> M: 215.588.6024 • @boneill42 <http://www.twitter.com/boneill42> •
>> healthmarketscience.com
>>
>> This information transmitted in this email message is for the intended
>> recipient only and may contain confidential and/or privileged material.
>>If
>> you received this email in error and are not the intended recipient, or
>> the person responsible to deliver it to the intended recipient, please
>> contact the sender at the email above and delete this email and any
>> attachments and destroy any copies thereof. Any review, retransmission,
>> dissemination, copying or other use of, or taking any action in reliance
>> upon, this information by persons or entities other than the intended
>> recipient is strictly prohibited.
>>
>>
>>
>>
>>
>>
>>
>> On 12/6/13, 2:01 PM, "Jon Logan" <jm...@buffalo.edu> wrote:
>>
>>> 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 <pt...@gmail.com>
>>>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 <m....@gmail.com>
>>>> 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 <pt...@gmail.com>
>>>> 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$20cassandr
>>>>a/
>>>> 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 <m....@gmail.com>
>>>>>> 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 <pt...@gmail.com>
>>>>>> 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 <na...@nathanmarz.com>
>>>> 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 <ev...@yahoo-inc.com>
>>>>>>
>>>>>> 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" <pt...@gmail.com> 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 <xu...@gmail.com>
>>>>>>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 <pt...@gmail.com>
>>>>>>
>>>>>> 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
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>
>>>>
>>
>>
>
Re: [LEGAL] Storm Project Dependencies
Posted by "P. Taylor Goetz" <pt...@gmail.com>.
I think how we handle it depends on the answer to the LGPL dependency question.
If 0mq/JZMQ has to be ripped out, it will be extracted and moved outside Apache so we can release.
If it can stay, then I’d like to see it move to its own module alongside the storm-netty module. That would also make it easier to modify the build process so users can build only the modules they want/need (default would be all modules).
When/if that happens depends on an answer to the license question, and the level of effort required to extract the 0mq transport to it’s own module.
I’m not aware of a JIRA for it, but one can be submitted here [1] (I can’t access JIRA at the moment).
[1] https://issues.apache.org/jira/browse/STORM
On Dec 6, 2013, at 11:06 AM, Brian O'Neill <bo...@alumni.brown.edu> wrote:
>
> Minimally (and not sure if it suffices for legal reqs), Storm should be
> able to build without JZMQ. (ASAP, IMHO =)
>
> Has that been taken care of already? (is there an issue created for that?)
>
> -brian
>
> ---
> Brian O'Neill
> Chief Architect
> Health Market Science
> The Science of Better Results
> 2700 Horizon Drive • King of Prussia, PA • 19406
> M: 215.588.6024 • @boneill42 <http://www.twitter.com/boneill42> •
> healthmarketscience.com
>
> This information transmitted in this email message is for the intended
> recipient only and may contain confidential and/or privileged material. If
> you received this email in error and are not the intended recipient, or
> the person responsible to deliver it to the intended recipient, please
> contact the sender at the email above and delete this email and any
> attachments and destroy any copies thereof. Any review, retransmission,
> dissemination, copying or other use of, or taking any action in reliance
> upon, this information by persons or entities other than the intended
> recipient is strictly prohibited.
>
>
>
>
>
>
>
> On 12/6/13, 2:01 PM, "Jon Logan" <jm...@buffalo.edu> wrote:
>
>> 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 <pt...@gmail.com> 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 <m....@gmail.com>
>>> 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 <pt...@gmail.com>
>>> 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 <m....@gmail.com>
>>>>> 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 <pt...@gmail.com>
>>>>> 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 <na...@nathanmarz.com>
>>> 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 <ev...@yahoo-inc.com>
>>>>>
>>>>> 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" <pt...@gmail.com> 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 <xu...@gmail.com> 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 <pt...@gmail.com>
>>>>>
>>>>> 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
>>>>>
>>>>>
>>>>>
>>>>>
>>>
>>>
>
>
Re: [LEGAL] Storm Project Dependencies
Posted by Brian O'Neill <bo...@alumni.brown.edu>.
Minimally (and not sure if it suffices for legal reqs), Storm should be
able to build without JZMQ. (ASAP, IMHO =)
Has that been taken care of already? (is there an issue created for that?)
-brian
---
Brian O'Neill
Chief Architect
Health Market Science
The Science of Better Results
2700 Horizon Drive • King of Prussia, PA • 19406
M: 215.588.6024 • @boneill42 <http://www.twitter.com/boneill42> •
healthmarketscience.com
This information transmitted in this email message is for the intended
recipient only and may contain confidential and/or privileged material. If
you received this email in error and are not the intended recipient, or
the person responsible to deliver it to the intended recipient, please
contact the sender at the email above and delete this email and any
attachments and destroy any copies thereof. Any review, retransmission,
dissemination, copying or other use of, or taking any action in reliance
upon, this information by persons or entities other than the intended
recipient is strictly prohibited.
On 12/6/13, 2:01 PM, "Jon Logan" <jm...@buffalo.edu> wrote:
>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 <pt...@gmail.com> 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 <m....@gmail.com>
>> 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 <pt...@gmail.com>
>> 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 <m....@gmail.com>
>> >> 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 <pt...@gmail.com>
>> >> 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 <na...@nathanmarz.com>
>>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 <ev...@yahoo-inc.com>
>> >>
>> >> 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" <pt...@gmail.com> 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 <xu...@gmail.com> 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 <pt...@gmail.com>
>> >>
>> >> 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
>> >>
>> >>
>> >>
>> >>
>>
>>
Re: [LEGAL] Storm Project Dependencies
Posted by Jon Logan <jm...@buffalo.edu>.
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 <pt...@gmail.com> 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 <m....@gmail.com>
> 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 <pt...@gmail.com>
> 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 <m....@gmail.com>
> >> 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 <pt...@gmail.com>
> >> 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 <na...@nathanmarz.com> 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 <ev...@yahoo-inc.com>
> >>
> >> 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" <pt...@gmail.com> 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 <xu...@gmail.com> 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 <pt...@gmail.com>
> >>
> >> 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
> >>
> >>
> >>
> >>
>
>
[LEGAL] Storm Project Dependencies
Posted by "P. Taylor Goetz" <pt...@gmail.com>.
(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 <m....@gmail.com> 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 <pt...@gmail.com> 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 <m....@gmail.com>
>> 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 <pt...@gmail.com>
>> 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 <na...@nathanmarz.com> 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 <ev...@yahoo-inc.com>
>>
>> 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" <pt...@gmail.com> 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 <xu...@gmail.com> 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 <pt...@gmail.com>
>>
>> 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
>>
>>
>>
>>
Re: [DISCUSS] Time to release 0.9.0?
Posted by Matt Franklin <m....@gmail.com>.
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 <pt...@gmail.com> 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 <m....@gmail.com>
> 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 <pt...@gmail.com>
> 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 <na...@nathanmarz.com> 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 <ev...@yahoo-inc.com>
>
> 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" <pt...@gmail.com> 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 <xu...@gmail.com> 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 <pt...@gmail.com>
>
> 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
>
>
>
>
Re: [DISCUSS] Time to release 0.9.0?
Posted by "P. Taylor Goetz" <pt...@gmail.com>.
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 <m....@gmail.com> 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 <pt...@gmail.com> 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 <na...@nathanmarz.com> 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 <ev...@yahoo-inc.com>
>> 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" <pt...@gmail.com> 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 <xu...@gmail.com> 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 <pt...@gmail.com>
>> 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
>>
Re: [DISCUSS] Time to release 0.9.0?
Posted by Matt Franklin <m....@gmail.com>.
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 <pt...@gmail.com> 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 <na...@nathanmarz.com> 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 <ev...@yahoo-inc.com>
> 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" <pt...@gmail.com> 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 <xu...@gmail.com> 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 <pt...@gmail.com>
> 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
>
Re: [DISCUSS] Time to release 0.9.0?
Posted by "P. Taylor Goetz" <pt...@gmail.com>.
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 <na...@nathanmarz.com> 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 <ev...@yahoo-inc.com> 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" <pt...@gmail.com> 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 <xu...@gmail.com> 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 <pt...@gmail.com> 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
Re: [DISCUSS] Time to release 0.9.0?
Posted by Nathan Marz <na...@nathanmarz.com>.
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 <ev...@yahoo-inc.com> 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" <pt...@gmail.com> 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 <xu...@gmail.com> 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 <pt...@gmail.com> 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
Re: [DISCUSS] Time to release 0.9.0?
Posted by "P. Taylor Goetz" <pt...@gmail.com>.
Thanks for volunteering to help out with this Bobby.
We can figure out what we want to do in terms of CI once we get 0.9.0 out the door and can focus on moving to the Apache process.
- Taylor
> On Nov 27, 2013, at 11:38 AM, Bobby Evans <ev...@yahoo-inc.com> 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" <pt...@gmail.com> 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 <xu...@gmail.com> 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 <pt...@gmail.com> 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
>>>
>>
>
Re: [DISCUSS] Time to release 0.9.0?
Posted by Bobby Evans <ev...@yahoo-inc.com>.
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" <pt...@gmail.com> 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 <xu...@gmail.com> 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 <pt...@gmail.com> 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
>>
>
Re: [DISCUSS] Time to release 0.9.0?
Posted by "P. Taylor Goetz" <pt...@gmail.com>.
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 <xu...@gmail.com> 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 <pt...@gmail.com> 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
>
Re: [DISCUSS] Time to release 0.9.0?
Posted by James Xu <xu...@gmail.com>.
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 <pt...@gmail.com> 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