storm-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ethan Li <ethanopensou...@gmail.com>
Subject Re: [DISCUSS] Next 2.x release
Date Mon, 19 Aug 2019 16:15:16 GMT
Many issues came up while I was preparing for 2.1.0 release. Freezing merge until the release is done is not practical.  So I am proposing:

1. Once we decide to make a release, we create a new branch based on master and start release process. 
2. During the new process, master is still open for backwards compatibility commits, including new features, bug fixes, etc. 
3. Only bug fixes will be merged to the new branch and we need to restart the release process to include the bug fixes.
4. To avoid too much confusion on pom versions when we merge new commits during the release process,  we should use less concrete version. For example, in 2.1.x-branch, the pom version should be 2.1-SNAPSHOT, instead of 2.1.0-SNAPSHOT. 

For example,

Let’s say we have a new branch 2.1.x-branch, the pom version is 2.1.0-SNAPSHOT. We start the release process and after running the mvn release:prepare -Pxxx command, the pom version changes to 2.1.1-SNAPSHOT, and before that a git tag v2.1.0 is created.  Now if there is a bug fix we have to merge in, so we merge in and it’s actually merged in to 2.1.1-SNAPSHOT at this point if we don’t manually revert the pom version, which can be confusing.  We can avoid this problem by just using 2.1-SNAPSHOT as the pom version. So it doesn’t have to change. 

Please let me know if there is any potential risk for doing this.

Thanks
Ethan

> On Aug 19, 2019, at 10:25 AM, Ethan Li <ethanopensource@gmail.com> wrote:
> 
> The pull request for the fix is https://github.com/apache/storm/pull/3106 <https://github.com/apache/storm/pull/3106>
> 
>> On Aug 19, 2019, at 10:15 AM, Ethan Li <ethanopensource@gmail.com <mailto:ethanopensource@gmail.com>> wrote:
>> 
>> So I was preparing for a new release candidate i.e. rc3. I can build it from source without any problem. Then I set up a standalone cluster and submitted a WordCountTopology. The workers kept restarting because of 
>> 
>> 
>> 2019-08-19 15:09:49.635 o.a.s.t.ShellBolt Thread-30 [ERROR] Halting process: ShellBolt died. Command: [python, splitsentence.py], ProcessInfo pid:3756, name:split exitCode:-1, errorString:
>> java.lang.IllegalArgumentException: command sync is not supported
>>         at org.apache.storm.task.ShellBolt$BoltReaderRunnable.run(ShellBolt.java:366) [storm-client-2.1.0.jar:2.1.0]
>>         at java.lang.Thread.run(Thread.java:748) [?:1.8.0_181]
>> 2019-08-19 15:09:49.635 o.a.s.e.e.ReportError Thread-30 [ERROR] Error
>> java.lang.IllegalArgumentException: command sync is not supported
>>         at org.apache.storm.task.ShellBolt$BoltReaderRunnable.run(ShellBolt.java:366) [storm-client-2.1.0.jar:2.1.0]
>>         at java.lang.Thread.run(Thread.java:748) [?:1.8.0_181]
>> 2019-08-19 15:09:49.636 o.a.s.t.ShellBolt Thread-28 [ERROR] Halting process: ShellBolt died. Command: [python, splitsentence.py], ProcessInfo pid:3755, name:split exitCode:-1, errorString:
>> java.lang.IllegalArgumentException: command sync is not supported
>>         at org.apache.storm.task.ShellBolt$BoltReaderRunnable.run(ShellBolt.java:366) [storm-client-2.1.0.jar:2.1.0]
>>         at java.lang.Thread.run(Thread.java:748) [?:1.8.0_181]
>> 2019-08-19 15:09:49.637 o.a.s.e.e.ReportError Thread-28 [ERROR] Error
>> java.lang.IllegalArgumentException: command sync is not supported
>>         at org.apache.storm.task.ShellBolt$BoltReaderRunnable.run(ShellBolt.java:366) [storm-client-2.1.0.jar:2.1.0]
>>         at java.lang.Thread.run(Thread.java:748) [?:1.8.0_181]
>> 
>> 
>> 
>> https://github.com/apache/storm/blob/master/storm-client/src/jvm/org/apache/storm/task/ShellBolt.java#L365-L367 <https://github.com/apache/storm/blob/master/storm-client/src/jvm/org/apache/storm/task/ShellBolt.java#L365-L367> I believe we shouldn’t throw exceptions here. 
>> 
>> Will make a pull request to fix it. 
>> 
>> 
>> 
>>> On Aug 14, 2019, at 11:11 PM, Ethan Li <ethanopensource@gmail.com <mailto:ethanopensource@gmail.com>> wrote:
>>> 
>>> Hi Taylor,
>>> 
>>> Mostly I was able to follow the doc https://github.com/apache/storm/blob/master/RELEASING.md#setting-up-a-vote <https://github.com/apache/storm/blob/master/RELEASING.md#setting-up-a-vote>, except:
>>> 
>>> For Step 1,  I used the following command as suggested.
>>> mvn release:prepare -P dist,rat,externals,examples
>>> mvn release:perform -P dist,rat,externals,examples
>>> 
>>> 
>>> For Step3,  I had to run "git checkout tags/v2.1.0 -b v2.1.0” so that I can run “mvn package” for storm-dist/binary and storm-dist/source based on v2.1.0. Otherwise if I run “mvn package” on 2.1.x-branch, it will fail because the pom version is “2.1.x-SNAPSHOT”. 
>>> 
>>> Then I find packages in storm-dist/binary/final-package/target and storm-dist/source/target, sign them, generate checksum and copy them to svn.
>>> 
>>> I think there are something I should do. But please let me know if I was doing something wrong.  I will  also update the doc after the release is complete. Thank you very much!
>>> 
>>> Ethan
>>> 
>>> 
>>>> On Aug 14, 2019, at 12:24 PM, Ethan Li <ethanopensource@gmail.com <mailto:ethanopensource@gmail.com>> wrote:
>>>> 
>>>> I am continuing for another release candidate since the pr is merged. 
>>>> 
>>>>> On Aug 13, 2019, at 11:58 AM, Stig Rohde Døssing <stigdoessing@gmail.com <mailto:stigdoessing@gmail.com>> wrote:
>>>>> 
>>>>> Updated https://github.com/apache/storm/pull/3053 <https://github.com/apache/storm/pull/3053> so we don't have
>>>>> org.apache.storm artifacts in the DEPENDENCY-LICENSES file. It's ready for
>>>>> review if someone wants to look at it.
>>>>> 
>>>>> Den tir. 13. aug. 2019 kl. 18.21 skrev Ethan Li <ethanopensource@gmail.com <mailto:ethanopensource@gmail.com>>:
>>>>> 
>>>>>> Thank you, Taylor. Will delete them.
>>>>>> 
>>>>>>> On Aug 13, 2019, at 11:19 AM, P. Taylor Goetz <ptgoetz@gmail.com <mailto:ptgoetz@gmail.com>> wrote:
>>>>>>> 
>>>>>>> Those can be safely deleted.
>>>>>>> 
>>>>>>> -Taylor
>>>>>>> 
>>>>>>>> On Aug 13, 2019, at 12:15 PM, Ethan Li <ethanopensource@gmail.com <mailto:ethanopensource@gmail.com>>
>>>>>> wrote:
>>>>>>>> 
>>>>>>>> Do we need/want to clean up the release candidate from
>>>>>> https://dist.apache.org/repos/dist/dev/storm <https://dist.apache.org/repos/dist/dev/storm> <
>>>>>> https://dist.apache.org/repos/dist/dev/storm <https://dist.apache.org/repos/dist/dev/storm>> ?
>>>>>>>> 
>>>>>>>> 
>>>>>> https://github.com/apache/storm/blob/master/RELEASING.md#cleaning-up-if-the-vote-fails <https://github.com/apache/storm/blob/master/RELEASING.md#cleaning-up-if-the-vote-fails>
>>>>>> <
>>>>>> https://github.com/apache/storm/blob/master/RELEASING.md#cleaning-up-if-the-vote-fails <https://github.com/apache/storm/blob/master/RELEASING.md#cleaning-up-if-the-vote-fails>>
>>>>>> says we do. But we have a lot of rc in
>>>>>> https://dist.apache.org/repos/dist/dev/storm/ <https://dist.apache.org/repos/dist/dev/storm/> <
>>>>>> https://dist.apache.org/repos/dist/dev/storm/ <https://dist.apache.org/repos/dist/dev/storm/>>
>>>>>>>> 
>>>>>>>> Just want to be absolutely sure about this. Thanks.
>>>>>>>> 
>>>>>>>>> On Aug 13, 2019, at 10:56 AM, Ethan Li <ethanopensource@gmail.com <mailto:ethanopensource@gmail.com>>
>>>>>> wrote:
>>>>>>>>> 
>>>>>>>>> That sounds better. It will be easier for release. Thank you for
>>>>>> looking into this.
>>>>>>>>> 
>>>>>>>>>> On Aug 13, 2019, at 10:54 AM, Stig Rohde Døssing <
>>>>>> stigdoessing@gmail.com <mailto:stigdoessing@gmail.com>> wrote:
>>>>>>>>>> 
>>>>>>>>>> Makes sense. I'll take a look at it. Ideally I'd want the license
>>>>>> files to
>>>>>>>>>> just not include org.apache.storm artifacts. I don't think we need to
>>>>>> tell
>>>>>>>>>> people that the project depends on itself.
>>>>>>>>>> 
>>>>>>>>>> If we can exclude these artifacts from the lists, I don't think the
>>>>>> release
>>>>>>>>>> plugin needs to update these files.
>>>>>>>>>> 
>>>>>>>>>> Den tir. 13. aug. 2019 kl. 17.36 skrev Ethan Li <
>>>>>> ethanopensource@gmail.com <mailto:ethanopensource@gmail.com>>:
>>>>>>>>>> 
>>>>>>>>>>> Thanks Stig.
>>>>>>>>>>> 
>>>>>>>>>>> In this case, we probably should abort release process and get this
>>>>>> merged
>>>>>>>>>>> into master first. Also we need to make sure it works with “mvn
>>>>>>>>>>> release:prepare” since “ mvn release:prepare” will automatically
>>>>>> push two
>>>>>>>>>>> commits. For example,
>>>>>>>>>>> 
>>>>>>>>>>> (1) [maven-release-plugin] prepare release v2.1.0:  this commit
>>>>>> changes
>>>>>>>>>>> the pom version to 2.1.0, push the commit, and then create a git tag
>>>>>> v2.1.0.
>>>>>>>>>>> 
>>>>>>>>>>> (2)  [maven-release-plugin] prepare for next development iteration:
>>>>>> this
>>>>>>>>>>> commit changes the pom version to 2.1.1-SNAPSHOT.
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> We need DEPENDENCY-LICENSES to be updated on every step.
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>>> On Aug 13, 2019, at 10:24 AM, Stig Rohde Døssing <
>>>>>> stigdoessing@gmail.com <mailto:stigdoessing@gmail.com>>
>>>>>>>>>>> wrote:
>>>>>>>>>>>> 
>>>>>>>>>>>> Oops, sorry that's not right. The license plugin setup was disabled
>>>>>> in
>>>>>>>>>>>> https://github.com/apache/storm/pull/3031 <https://github.com/apache/storm/pull/3031> due to a bug in the
>>>>>> license
>>>>>>>>>>>> plugin. It is added back in
>>>>>> https://github.com/apache/storm/pull/3053 <https://github.com/apache/storm/pull/3053>,
>>>>>>>>>>>> where we've upgraded the plugin. Until that PR goes in, we can't
>>>>>> easily
>>>>>>>>>>>> regenerate DEPENDENCY-LICENSES.
>>>>>>>>>>>> 
>>>>>>>>>>>> Den tir. 13. aug. 2019 kl. 17.15 skrev Stig Rohde Døssing <
>>>>>>>>>>>> stigdoessing@gmail.com <mailto:stigdoessing@gmail.com>>:
>>>>>>>>>>>> 
>>>>>>>>>>>>> There's a script that can help you do it in
>>>>>>>>>>>>> https://github.com/apache/storm/pull/3053 <https://github.com/apache/storm/pull/3053>. It checks the
>>>>>>>>>>>>> DEPENDENCY-LICENSES and LICENSE-binary contain the right
>>>>>> dependencies,
>>>>>>>>>>> and
>>>>>>>>>>>>> prints which licenses are redundant or should be added.
>>>>>>>>>>>>> 
>>>>>>>>>>>>> For DEPENDENCY-LICENSES specifically you can run "mvn
>>>>>>>>>>>>> license:aggregate-add-third-party@generate-and-check-licenses
>>>>>>>>>>>>> -Dlicense.skipAggregateAddThirdParty=false -B" in the project
>>>>>> root. It
>>>>>>>>>>>>> should update the file for you.
>>>>>>>>>>>>> 
>>>>>>>>>>>>> Den tir. 13. aug. 2019 kl. 17.06 skrev Ethan Li <
>>>>>>>>>>> ethanopensource@gmail.com <mailto:ethanopensource@gmail.com>
>>>>>>>>>>>>>> :
>>>>>>>>>>>>> 
>>>>>>>>>>>>>> Hi Stig,
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> How do we update
>>>>>>>>>>>>>> https://github.com/apache/storm/blob/v2.1.0/DEPENDENCY-LICENSES? <https://github.com/apache/storm/blob/v2.1.0/DEPENDENCY-LICENSES?>
>>>>>> <
>>>>>>>>>>>>>> https://github.com/apache/storm/blob/v2.1.0/DEPENDENCY-LICENSES? <https://github.com/apache/storm/blob/v2.1.0/DEPENDENCY-LICENSES?>>
>>>>>> Is
>>>>>>>>>>>>>> there a command I can use? Or I just replace strings manually?
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> Thanks
>>>>>>>>>>>>>> Ethan
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> On Aug 12, 2019, at 3:54 PM, Ethan Li <ethanopensource@gmail.com <mailto:ethanopensource@gmail.com>
>>>>>>> 
>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> Yes my public keys in that file. Thanks! Ready to set up a vote.
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> On Aug 12, 2019, at 3:52 PM, P. Taylor Goetz <ptgoetz@gmail.com <mailto:ptgoetz@gmail.com>
>>>>>>> 
>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> Yes. Is you public key in that file? If not you should add it.
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> -Taylor
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>> On Aug 12, 2019, at 4:15 PM, Ethan Li <
>>>>>> ethanopensource@gmail.com <mailto:ethanopensource@gmail.com>>
>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>> I have one more question before I can start a vote.
>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>> In previous [VOTE] thread, Taylor always has this:
>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>> The release artifacts are signed with the following key:
>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>> https://git-wip-us.apache.org/repos/asf?p=storm.git;a=blob_plain;f=KEYS;hb=22b832708295fa2c15c4f3c70ac0d2bc6fded4bd <https://git-wip-us.apache.org/repos/asf?p=storm.git;a=blob_plain;f=KEYS;hb=22b832708295fa2c15c4f3c70ac0d2bc6fded4bd>
>>>>>>>>>>>>>> <
>>>>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>> https://git-wip-us.apache.org/repos/asf?p=storm.git;a=blob_plain;f=KEYS;hb=22b832708295fa2c15c4f3c70ac0d2bc6fded4bd <https://git-wip-us.apache.org/repos/asf?p=storm.git;a=blob_plain;f=KEYS;hb=22b832708295fa2c15c4f3c70ac0d2bc6fded4bd>
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>> Does anyone know where to find the updated KEYs file? Should I
>>>>>> just
>>>>>>>>>>>>>> use https://www.apache.org/dist/storm/KEYS <
>>>>>>>>>>>>>> https://www.apache.org/dist/storm/KEYS> ?
>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>> Thanks very much
>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>> On Aug 12, 2019, at 9:44 AM, Ethan Li <
>>>>>> ethanopensource@gmail.com>
>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>> Thanks Stig and Taylor! It worked. I will continue the
>>>>>> process now
>>>>>>>>>>>>>> and update the documentation later.
>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>> On Aug 12, 2019, at 9:40 AM, P. Taylor Goetz <
>>>>>> ptgoetz@gmail.com>
>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>> For the 2.x version lines, there are a bunch of profiles you
>>>>>> need
>>>>>>>>>>>>>> to enable. This is what I use when preparing a release:
>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>> -P dist,include-shaded-deps,rat,externals,examples
>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>> -Taylor
>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>> On Aug 12, 2019, at 9:27 AM, Stig Rohde Døssing <
>>>>>>>>>>>>>> stigdoessing@gmail.com> wrote:
>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>> Try enabling the "dist" profile by adding "-P
>>>>>>>>>>>>>> dist,externals,examples" to
>>>>>>>>>>>>>>>>>>>> the command you're running. See
>>>>>>>>>>>>>>>>>>>> https://github.com/apache/storm/blob/master/pom.xml#L518.
>>>>>> Unless
>>>>>>>>>>>>>> you enable
>>>>>>>>>>>>>>>>>>>> that profile, the storm-dist modules aren't in the reactor.
>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>> Den man. 12. aug. 2019 kl. 15.15 skrev Ethan Li <
>>>>>>>>>>>>>> ethanopensource@gmail.com>:
>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>> Just in case if anyone happens to know the answer:
>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>> I created a branch
>>>>>>>>>>>>>> https://github.com/apache/storm/tree/2.1.x-branch <
>>>>>>>>>>>>>>>>>>>>> https://github.com/apache/storm/tree/2.1.x-branch> and ran
>>>>>>>>>>>>>> “mvn:prepare”
>>>>>>>>>>>>>>>>>>>>> and “mvn:perform”. It created two commits and created a
>>>>>> v2.1.0
>>>>>>>>>>>>>> git tag. But
>>>>>>>>>>>>>>>>>>>>> I realized that the pom version under storm-dist was not
>>>>>> updated
>>>>>>>>>>>>>> and it’s
>>>>>>>>>>>>>>>>>>>>> still 2.0.1-SNAPSHOT. I checked the commits in other tags
>>>>>> like
>>>>>>>>>>>>>>>>>>>>> https://github.com/apache/storm/commits/v2.0.0 <
>>>>>>>>>>>>>>>>>>>>> https://github.com/apache/storm/commits/v2.0.0> and it
>>>>>> looks
>>>>>>>>>>> like
>>>>>>>>>>>>>>>>>>>>> storm-dist got updated within the “mvn:prepare” step.  How
>>>>>> do I
>>>>>>>>>>>>>> get
>>>>>>>>>>>>>>>>>>>>> storm-dist pom version updated with “mv:prepare”?
>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>> I am currently blocked on this. Any help will be
>>>>>> appreciated.
>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>>>>>>>>> Ethan
>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>> On Aug 12, 2019, at 2:38 AM, Stig Rohde Døssing <
>>>>>>>>>>>>>> stigdoessing@gmail.com>
>>>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>> Sounds good Ethan.
>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>> Derek, I also think being clear about how long we expect
>>>>>> to
>>>>>>>>>>>>>> support a
>>>>>>>>>>>>>>>>>>>>>> release line is a good idea. Maybe we should do a separate
>>>>>>>>>>>>>> discuss thread
>>>>>>>>>>>>>>>>>>>>>> on this, or if you already have a good idea for what the
>>>>>> policy
>>>>>>>>>>>>>> should
>>>>>>>>>>>>>>>>>>>>> look
>>>>>>>>>>>>>>>>>>>>>> like you could put it up as a PR for either the Downloads
>>>>>> page
>>>>>>>>>>>>>> or a new
>>>>>>>>>>>>>>>>>>>>>> page on the Storm site?
>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>> Den søn. 11. aug. 2019 kl. 08.37 skrev Ethan Li <
>>>>>>>>>>>>>>>>>>>>> ethanopensource@gmail.com>:
>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>> I am doing the release following
>>>>>>>>>>>>>>>>>>>>>>> https://github.com/apache/storm/blob/master/RELEASING.md
>>>>>> <
>>>>>>>>>>>>>>>>>>>>>>> https://github.com/apache/storm/blob/master/RELEASING.md>
>>>>>> . I
>>>>>>>>>>>>>> made some
>>>>>>>>>>>>>>>>>>>>>>> progress but I have some questions so I just sent an
>>>>>> email to
>>>>>>>>>>>>>> Taylor.
>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>> Please don’t merge anything to master or 2.1.x-branch
>>>>>> for now.
>>>>>>>>>>>>>> Thanks
>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>> Best,
>>>>>>>>>>>>>>>>>>>>>>> Ethan
>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>> On Aug 9, 2019, at 4:45 PM, Ethan Li <
>>>>>>>>>>>>>> ethanopensource@gmail.com>
>>>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>> Currently we have two outstanding PRs that we wanted to
>>>>>>>>>>>>>> include in the
>>>>>>>>>>>>>>>>>>>>>>> new release:
>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>> https://github.com/apache/storm/pull/3096 <
>>>>>>>>>>>>>>>>>>>>>>> https://github.com/apache/storm/pull/3096> (Travis has
>>>>>> some
>>>>>>>>>>>>>> issues
>>>>>>>>>>>>>>>>>>>>>>> connecting to repository.apache.org <
>>>>>>>>>>>>>> http://repository.apache.org/>
>>>>>>>>>>>>>>>>>>>>>>> recently. Travis build fails consistently)
>>>>>>>>>>>>>>>>>>>>>>>> https://github.com/apache/storm/pull/2878 <
>>>>>>>>>>>>>>>>>>>>>>> https://github.com/apache/storm/pull/2878> (Some
>>>>>> comments are
>>>>>>>>>>>>>> to be
>>>>>>>>>>>>>>>>>>>>>>> addressed but Author hasn’t responded yet.)
>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>> It’s not absolutely necessary to include them in this
>>>>>> new
>>>>>>>>>>>>>> release so I
>>>>>>>>>>>>>>>>>>>>>>> think I should move forward with the release process.
>>>>>> These
>>>>>>>>>>> two
>>>>>>>>>>>>>> and
>>>>>>>>>>>>>>>>>>>>> other
>>>>>>>>>>>>>>>>>>>>>>> PRs can be included in the next release.
>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>> For the release, I will create a new branch 2.1.x-branch
>>>>>>>>>>> based
>>>>>>>>>>>>>> on
>>>>>>>>>>>>>>>>>>>>>>> current master branch, and release 2.1.0 from there.   I
>>>>>> will
>>>>>>>>>>>>>> then move
>>>>>>>>>>>>>>>>>>>>>>> master to 2.2.0-SNAPSHOT.  Please let me know if there
>>>>>> is any
>>>>>>>>>>>>>>>>>>>>> objections.
>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>>>>>>>>>>>> Ethan
>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>> On Aug 9, 2019, at 2:53 PM, Derek Dagit <
>>>>>> dagit@apache.org
>>>>>>>>>>>>>> <mailto:
>>>>>>>>>>>>>>>>>>>>>>> dagit@apache.org>> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>> We might not able to say how long we want to support a
>>>>>>>>>>>>>> specific
>>>>>>>>>>>>>>>>>>>>>>>>>> release line but I would love to see a clear release
>>>>>> policy
>>>>>>>>>>>>>> being
>>>>>>>>>>>>>>>>>>>>>>>>>> made.
>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>> That makes sense. It seems better for us not to choose
>>>>>> a
>>>>>>>>>>>>>> specific
>>>>>>>>>>>>>>>>>>>>>>>>> calendar date or duration of time.
>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>> - We do not want too many release lines supported
>>>>>>>>>>>>>> concurrently.
>>>>>>>>>>>>>>>>>>>>>>>>> - We want devs and users to know what to expect.
>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>>>>>>>>> Derek
>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>> On Fri, Aug 09, 2019 at 10:32:59AM -0500, Ethan Li
>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>> Derek,
>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>> I think it’s a good idea to be more clear on the
>>>>>> versioning
>>>>>>>>>>>>>> and
>>>>>>>>>>>>>>>>>>>>>>> release process so users and developers know what to
>>>>>> expect.
>>>>>>>>>>> We
>>>>>>>>>>>>>> might
>>>>>>>>>>>>>>>>>>>>> not
>>>>>>>>>>>>>>>>>>>>>>> able to say how long we want to support a specific
>>>>>> release
>>>>>>>>>>> line
>>>>>>>>>>>>>> but I
>>>>>>>>>>>>>>>>>>>>> would
>>>>>>>>>>>>>>>>>>>>>>> love to see a clear release policy being made.
>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>>>>>>>>>>>>>> Ethan
>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>>> On Aug 9, 2019, at 8:53 AM, Derek Dagit <
>>>>>> dagit@apache.org
>>>>>>>>>>>>>> <mailto:
>>>>>>>>>>>>>>>>>>>>>>> dagit@apache.org>> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>>> On Fri, Aug 09, 2019 at 02:35:57PM +0200, Stig Rohde
>>>>>>>>>>>>>> Døssing wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>> Where on the Traffic Server page do they list how
>>>>>> long
>>>>>>>>>>>>>> their
>>>>>>>>>>>>>>>>>>>>> release
>>>>>>>>>>>>>>>>>>>>>>>>>>>> trains survive? I only see dates of release, not
>>>>>> how long
>>>>>>>>>>>>>> e.g. 7.x
>>>>>>>>>>>>>>>>>>>>> is
>>>>>>>>>>>>>>>>>>>>>>>>>>>> supposed to receive support.  Derek,
>>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>>> This is a better link:
>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> https://cwiki.apache.org/confluence/display/TS/Release+Management
>>>>>> <
>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> https://cwiki.apache.org/confluence/display/TS/Release+Management
>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>>> This example, where "RM" means "Release Manager":
>>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>>>> 1. We promise to make 1 major release / year, but
>>>>>> the RM
>>>>>>>>>>>>>> and
>>>>>>>>>>>>>>>>>>>>>>> community
>>>>>>>>>>>>>>>>>>>>>>>>>>>> can of course make more as necessary
>>>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>>>> 2. We only make releases off the LTS branches,
>>>>>> which are
>>>>>>>>>>>>>> cut once a
>>>>>>>>>>>>>>>>>>>>>>>>>>>> year off master
>>>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>>>> 3. Master is always open, for any type of change
>>>>>>>>>>> (including
>>>>>>>>>>>>>>>>>>>>>>>>>>>> incompatible changes). But don't break
>>>>>> compatibility just
>>>>>>>>>>>>>> for fun!
>>>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>>>> 4. Master is always stable, i.e. commits should be
>>>>>>>>>>>>>> properly tested
>>>>>>>>>>>>>>>>>>>>>>> and
>>>>>>>>>>>>>>>>>>>>>>>>>>>> reviewed before committed to master.
>>>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>>>> 5. All releases are stable releases, following
>>>>>> strict
>>>>>>>>>>>>>> Semantic
>>>>>>>>>>>>>>>>>>>>>>>>>>>> Versioning.
>>>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>>>> 6. Minor releases are made at the discretion at the
>>>>>>>>>>>>>> discretion of
>>>>>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>>>>>>>>>>> community and the RM.
>>>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>>>> 7. Minor releases can include new (small / safe)
>>>>>>>>>>> features,
>>>>>>>>>>>>>> but must
>>>>>>>>>>>>>>>>>>>>>>> be
>>>>>>>>>>>>>>>>>>>>>>>>>>>> compatible within the LTS major version.
>>>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>>>> 8. The LTS cycle, 2 years + 6 months Sunset, does
>>>>>> not
>>>>>>>>>>>>>> reset when we
>>>>>>>>>>>>>>>>>>>>>>>>>>>> make a minor release.
>>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>>> Now, I am not proposing we do exactly this. The goal
>>>>>> would
>>>>>>>>>>>>>> be to set
>>>>>>>>>>>>>>>>>>>>>>>>>>> expectations among developers and the community, and
>>>>>> here
>>>>>>>>>>>>>> is one
>>>>>>>>>>>>>>>>>>>>>>>>>>> concrete example of how it could be done.
>>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>>>> If we're going to promise that a release line
>>>>>> survives
>>>>>>>>>>> for
>>>>>>>>>>>>>> a given
>>>>>>>>>>>>>>>>>>>>>>>>>>>> amount of time, I think we should do it at the major
>>>>>>>>>>>>>> version level
>>>>>>>>>>>>>>>>>>>>>>>>>>>> only
>>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>>> Yeah, that sounds reasonable to me. If we choose to
>>>>>> commit
>>>>>>>>>>>>>> to
>>>>>>>>>>>>>>>>>>>>>>> something
>>>>>>>>>>>>>>>>>>>>>>>>>>> like the above, we should base the decision in part
>>>>>> on
>>>>>>>>>>> what
>>>>>>>>>>>>>> kind of
>>>>>>>>>>>>>>>>>>>>>>>>>>> resources we have so that we do not over-commit.
>>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>>>> Den fre. 9. aug. 2019 kl. 00.15 skrev Derek Dagit <
>>>>>>>>>>>>>>>>>>>>> dagit@apache.org
>>>>>>>>>>>>>>>>>>>>>>> <mailto:dagit@apache.org>>:
>>>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> What do we think about defining Long-Term Support
>>>>>>>>>>>>>> branches with a
>>>>>>>>>>>>>>>>>>>>>>> fixed
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> period of support?
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> For example, we could say 2.0.x is an LTS release
>>>>>> line
>>>>>>>>>>>>>> with
>>>>>>>>>>>>>>>>>>>>> support
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> ending no earlier than a certain calendar date.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> The date could be extended, and it might
>>>>>> ultimately be
>>>>>>>>>>>>>> governed by
>>>>>>>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> timing of the subsequent release (e.g., 2.1.x or
>>>>>> 3.0.x).
>>>>>>>>>>>>>> Keeping
>>>>>>>>>>>>>>>>>>>>>>> things
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> clear would imply semantic versioning as mentioned
>>>>>>>>>>> earlier
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> (https://semver.org/ <https://semver.org/>).
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Apache Traffic Server does something like this, to
>>>>>> name
>>>>>>>>>>>>>> one
>>>>>>>>>>>>>>>>>>>>> project:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> https://trafficserver.apache.org/downloads <
>>>>>>>>>>>>>>>>>>>>>>> https://trafficserver.apache.org/downloads>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Having a regular cadence of releases might also
>>>>>> help
>>>>>>>>>>> make
>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>>>>>> process
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> easier and help set expectations for users and
>>>>>> devs.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Derek
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On Thu, Aug 08, 2019 at 02:50:07PM -0500, Ethan Li
>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Currently we don’t have a 2.0.x-branch and master
>>>>>> is
>>>>>>>>>>>>>> actually
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> “2.0.1-SNAPSHOT”.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> So if we  do a 2.1.0 release,  we will create a
>>>>>>>>>>>>>> 2.1.x-branch
>>>>>>>>>>>>>>>>>>>>> based
>>>>>>>>>>>>>>>>>>>>>>> on
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> current master, release from there. And we change
>>>>>> master
>>>>>>>>>>>>>> to
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> “2.2.0-SNAPSHOT”.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> But we will have one problem: we will lose 2.0.x
>>>>>>>>>>> release
>>>>>>>>>>>>>> line.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> There are two things I can do:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 1) create a 2.0.x-branch based on v2.0.0 tag.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 2) ignore it. If there is an issue with 2.0.x
>>>>>> release,
>>>>>>>>>>>>>> ask users
>>>>>>>>>>>>>>>>>>>>>>> to
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> upgrade to 2.1.0.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> I prefer 1) but not sure if it’s the right way to
>>>>>> make
>>>>>>>>>>>>>> things
>>>>>>>>>>>>>>>>>>>>>>> right. Or
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> please let me know if I misunderstood something
>>>>>> and it’s
>>>>>>>>>>>>>> not an
>>>>>>>>>>>>>>>>>>>>>>> issue.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Btw, I am seeing the same issue with 1.x-branch.
>>>>>> We
>>>>>>>>>>>>>> shouldn’t
>>>>>>>>>>>>>>>>>>>>> have
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 1.x-branch. Instead, we should have 1.2.x-branch.
>>>>>> But
>>>>>>>>>>>>>> this is not
>>>>>>>>>>>>>>>>>>>>> a
>>>>>>>>>>>>>>>>>>>>>>> problem
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> since we will not release 1.3.x.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Ethan
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On Aug 7, 2019, at 10:43 AM, Ethan Li <
>>>>>>>>>>>>>>>>>>>>> ethanopensource@gmail.com>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Yes thanks.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On Aug 7, 2019, at 10:39 AM, Stig Rohde Døssing
>>>>>> <
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> stigdoessing@gmail.com> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Sounds great. Remember to add your key to
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>> https://dist.apache.org/repos/dist/release/storm/KEYS,
>>>>>>>>>>>>>> you
>>>>>>>>>>>>>>>>>>>>>>> should be
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> able
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> to update it with an SVN client. See also
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> https://www.apache.org/dev/openpgp.html#update.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Den ons. 7. aug. 2019 kl. 15.05 skrev Ethan Li <
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> ethanopensource@gmail.com>:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> I got my pgp key signed by Bryan W. Call <
>>>>>>>>>>>>>> bcall@apache.org
>>>>>>>>>>>>>>>>>>>>>>> <mailto:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> bcall@apache.org>> (Thanks to him).
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> My pgp key:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>> http://pgp.surfnet.nl/pks/lookup?op=vindex&fingerprint=on&search=0xA4A672F11B5050C8
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> <
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>> http://pgp.surfnet.nl/pks/lookup?op=vindex&fingerprint=on&search=0xA4A672F11B5050C8
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> My understanding is that I am good to do
>>>>>> release
>>>>>>>>>>> with
>>>>>>>>>>>>>> this key
>>>>>>>>>>>>>>>>>>>>>>> now.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Here is a list of PRs that we might want to
>>>>>> include
>>>>>>>>>>>>>> in the new
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> release:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> https://github.com/apache/storm/pull/3098 <
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> https://github.com/apache/storm/pull/3098>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> https://github.com/apache/storm/pull/3096 <
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> https://github.com/apache/storm/pull/3096>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> https://github.com/apache/storm/pull/2878 <
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> https://github.com/apache/storm/pull/2878>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Please review if you get a chance.  Thanks
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Ethan
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On Aug 1, 2019, at 4:19 AM, Stig Rohde
>>>>>> Døssing <
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> stigdoessing@gmail.com>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Thanks Ethan, yes 2.1.0 makes sense.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Den man. 29. jul. 2019 kl. 23.43 skrev Ethan
>>>>>> Li <
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> ethanopensource@gmail.com>:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> It’s a good point. I will start a discussion
>>>>>>>>>>> thread
>>>>>>>>>>>>>> for it.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> For the new release, I went through the list:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>> https://issues.apache.org/jira/issues/?jql=project%20%3D%20STORM%20AND%20fixVersion%20%3D%202.0.1
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> <
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>> https://issues.apache.org/jira/issues/?jql=project%20=%20STORM%20AND%20fixVersion%20=%202.0.1
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> We introduced some new functionalities,
>>>>>> including
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>> https://issues.apache.org/jira/browse/STORM-2720
>>>>>>>>>>> <
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>> https://issues.apache.org/jira/browse/STORM-2720>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>> https://issues.apache.org/jira/browse/STORM-3412
>>>>>>>>>>> <
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>> https://issues.apache.org/jira/browse/STORM-3412>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>> https://issues.apache.org/jira/browse/STORM-3411
>>>>>>>>>>> <
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>> https://issues.apache.org/jira/browse/STORM-3411>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>> https://issues.apache.org/jira/browse/STORM-3442
>>>>>>>>>>> <
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>> https://issues.apache.org/jira/browse/STORM-3442>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>> https://issues.apache.org/jira/browse/STORM-3396
>>>>>>>>>>> <
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>> https://issues.apache.org/jira/browse/STORM-3396>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>> https://issues.apache.org/jira/browse/STORM-3392
>>>>>>>>>>> <
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>> https://issues.apache.org/jira/browse/STORM-3392>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>> https://issues.apache.org/jira/browse/STORM-3395
>>>>>>>>>>> <
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>> https://issues.apache.org/jira/browse/STORM-3395>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> So I think we should release 2.1.0 rather
>>>>>> than
>>>>>>>>>>>>>> 2.0.1.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> There are a few pull requests we may want to
>>>>>>>>>>> review
>>>>>>>>>>>>>> before
>>>>>>>>>>>>>>>>>>>>>>> the next
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> release:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> https://github.com/apache/storm/pull/3094 <
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> https://github.com/apache/storm/pull/3094>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> https://github.com/apache/storm/pull/2990 <
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> https://github.com/apache/storm/pull/2990>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> https://github.com/apache/storm/pull/2878 <
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> https://github.com/apache/storm/pull/2878>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Thanks
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Ethan
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On Jul 29, 2019, at 10:11 AM, Hugo Louro <
>>>>>>>>>>>>>>>>>>>>> hmclouro@gmail.com
>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> +1
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> I think it would facilitate more frequent
>>>>>>>>>>> releases
>>>>>>>>>>>>>> to
>>>>>>>>>>>>>>>>>>>>>>> summarize
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> in a
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> page
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> the testing that all
>>>>>> contributors/committers do
>>>>>>>>>>> in
>>>>>>>>>>>>>>>>>>>>>>> anticipation
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> of the
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> release, plus any "new" testing that may
>>>>>> become
>>>>>>>>>>>>>> relevant
>>>>>>>>>>>>>>>>>>>>> for
>>>>>>>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> newer
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> releases. Doing so would make it easy to
>>>>>> create a
>>>>>>>>>>>>>> check
>>>>>>>>>>>>>>>>>>>>> form
>>>>>>>>>>>>>>>>>>>>>>> or or
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> email
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> template that what we feel should be done to
>>>>>>>>>>>>>> guarantee a
>>>>>>>>>>>>>>>>>>>>>>> stable
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> release.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Hugo
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On Mon, Jul 29, 2019 at 7:15 AM Ethan Li <
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> ethanopensource@gmail.com>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Thanks Stig. I will look into it.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On Jul 26, 2019, at 3:06 PM, Stig Rohde
>>>>>>>>>>> Døssing <
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> stigdoessing@gmail.com>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> I think ideally we've been trying for
>>>>>> semver,
>>>>>>>>>>>>>> but it's
>>>>>>>>>>>>>>>>>>>>> been
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> pretty
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> loose,
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> e.g. there were breaking changes in one
>>>>>> of the
>>>>>>>>>>>>>> 1.2.x
>>>>>>>>>>>>>>>>>>>>>>> releases
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> for
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> storm-kafka-client. I don't know what
>>>>>> rules
>>>>>>>>>>> we've
>>>>>>>>>>>>>>>>>>>>> actually
>>>>>>>>>>>>>>>>>>>>>>> been
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> using,
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> if
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> any.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Semver for binary compatibility would
>>>>>> probably
>>>>>>>>>>>>>> be a good
>>>>>>>>>>>>>>>>>>>>>>> rule of
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> thumb.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Den fre. 26. jul. 2019 kl. 20.01 skrev
>>>>>> Ethan
>>>>>>>>>>> Li <
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> ethanopensource@gmail.com>:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Stig,
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Do you know what’s the versioning
>>>>>> standard we
>>>>>>>>>>>>>> have been
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> following
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> (to
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> determine a 2.0.1 release or 2.1.0
>>>>>> release) ?
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On Jul 26, 2019, at 12:26 PM, Stig Rohde
>>>>>>>>>>>>>> Døssing <
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> stigdoessing@gmail.com>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Sounds great, thanks Ethan.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Den fre. 26. jul. 2019 kl. 19.16 skrev
>>>>>> Ethan
>>>>>>>>>>>>>> Li <
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> ethanopensource@gmail.com>:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> It’s good idea to do more frequent
>>>>>> release.
>>>>>>>>>>> I
>>>>>>>>>>>>>> can run
>>>>>>>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> next
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> release.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> I will take a look at both PRs. Other
>>>>>> than
>>>>>>>>>>>>>> that, I
>>>>>>>>>>>>>>>>>>>>>>> think we
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> should
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> also
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> get
>>>>>>>>>>> https://github.com/apache/storm/pull/3093
>>>>>>>>>>>>>> <
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>> https://github.com/apache/storm/pull/3093>
>>>>>>>>>>>>>> in the
>>>>>>>>>>>>>>>>>>>>> new
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> release.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On Jul 26, 2019, at 11:58 AM, Stig
>>>>>> Rohde
>>>>>>>>>>>>>> Døssing <
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> stigdoessing@gmail.com>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Hi,
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> I think we've talked about more
>>>>>> frequent
>>>>>>>>>>>>>> releases
>>>>>>>>>>>>>>>>>>>>>>> before.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Releasing
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> new
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> versions every few months means people
>>>>>>>>>>> don't
>>>>>>>>>>>>>> have to
>>>>>>>>>>>>>>>>>>>>>>> wait
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> long
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> for
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> fixes
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> to
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> get out, and smaller releases are
>>>>>> probably
>>>>>>>>>>>>>> also
>>>>>>>>>>>>>>>>>>>>> easier
>>>>>>>>>>>>>>>>>>>>>>> for
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> users
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> to
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> get
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> to
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> grips with (the fix list for 2.0.0 is
>>>>>>>>>>>>>> enormous).
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> With that in mind, I think we should
>>>>>> start
>>>>>>>>>>>>>> looking at
>>>>>>>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> next
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 2.x
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> release
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> (2.0.1 or 2.1.0?), since it's been a
>>>>>> couple
>>>>>>>>>>>>>> of months
>>>>>>>>>>>>>>>>>>>>>>> since
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 2.0.0
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> released.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> The fix list would be
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>> https://issues.apache.org/jira/issues/?jql=project%20%3D%20STORM%20AND%20fixVersion%20%3D%202.0.1
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> .
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Govind and Ethan have offered to run
>>>>>> the
>>>>>>>>>>> next
>>>>>>>>>>>>>>>>>>>>> release,
>>>>>>>>>>>>>>>>>>>>>>> and
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> help
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> validate
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> our release process guidelines. Would
>>>>>> one
>>>>>>>>>>> of
>>>>>>>>>>>>>> you have
>>>>>>>>>>>>>>>>>>>>>>> time
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> to
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> work
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> on a
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> release in the near future?
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> It would be good to take a look at
>>>>>>>>>>> currently
>>>>>>>>>>>>>> open PRs
>>>>>>>>>>>>>>>>>>>>>>> and
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> decide
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> which
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> we
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> feel need to get merged before the
>>>>>> next
>>>>>>>>>>>>>> release.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> I would like to see at least
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> https://github.com/apache/storm/pull/2990
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> merged
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>> https://github.com/apache/storm/pull/2878
>>>>>>>>>>>>>> seems like
>>>>>>>>>>>>>>>>>>>>>>> it's
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> close
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> to
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> be
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> mergeable too?
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>> 
>>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>> 
>>> 
>> 
> 


Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message