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 Wed, 21 Aug 2019 15:27:07 GMT
As we agreed to create a 2.1.x-branch and any later critical bug fixes for 2.1.x will go into that branch, I think there is not point for master branch to freeze. 

There are many pull requests I’d like to merge and it potentially blocks some of our developments (for up to 20 days now). So I am proposing to free master branch and start merging pull requests. And if it’s a critical bug fix, we should merge it to 2.1.x-branch too. 

> On Aug 19, 2019, at 3:01 PM, Ethan Li <ethanopensource@gmail.com> wrote:
> 
> Yes we can revert the two commits before merging in a new commit if we decide to include this new commit to current version.
> 
> 
>> On Aug 19, 2019, at 2:57 PM, Stig Rohde Døssing <stigdoessing@gmail.com <mailto:stigdoessing@gmail.com>> wrote:
>> 
>>> Now if we need to merge something in (2.1.0 is not released yet), we
>> merge it to 2.1.x-branch.  But the current pom version is 2.1.1-SNAPSHOT,
>> which should really be 2.1.0-SNAPSHOT, because this commit goes into 2.1.0
>> version.  To fix this, we need to revert last two commits before we merge
>> the new commit.
>> 
>> Sure, but if we're merging anything to 2.1.x-branch during the release
>> process, we're either expecting it to go in 2.1.1 so 2.1.1-SNAPSHOT is the
>> right version, or we're cancelling the 2.1.0 vote in order to include it,
>> and in that case we're reverting those two commits anyway, right? I don't
>> think there's a problem with merging something in, and then reverting the
>> version bump in a later commit?
>> 
>> Den man. 19. aug. 2019 kl. 20.38 skrev Ethan Li <ethanopensource@gmail.com <mailto:ethanopensource@gmail.com>>:
>> 
>>> You are right. But I was talking about the pom version.
>>> 
>>> So if we have 2.1.x-branch and the pom version is 2.1.0-SNAPSHOT. If we
>>> start release process here, i.e. run “mvn release:prepare”,  it will create
>>> and push two commits automatically.
>>> 
>>> First commit: change pom version to 2.1.0; and create a v2.1.0 git tag.
>>> Second commit: change pom version to 2.1.1-SNAPSHOT.
>>> 
>>> So now in 2.1.x-branch, the pom version is 2.1.1-SNAPSHOT.
>>> 
>>> Now if we need to merge something in (2.1.0 is not released yet), we merge
>>> it to 2.1.x-branch.  But the current pom version is 2.1.1-SNAPSHOT, which
>>> should really be 2.1.0-SNAPSHOT, because this commit goes into 2.1.0
>>> version.  To fix this, we need to revert last two commits before we merge
>>> the new commit.
>>> 
>>> If we use 2.1-SNAPSHOT, we don’t need to revert.
>>> 
>>> With that being said, I am fine with reverting if needed.  It’s probably
>>> safe to not change the convention.
>>> 
>>> 
>>> 
>>>> On Aug 19, 2019, at 1:24 PM, Stig Rohde Døssing <stigdoessing@gmail.com <mailto:stigdoessing@gmail.com>>
>>> wrote:
>>>> 
>>>> Ok, that makes sense. I still don't understand the need for 2.1-SNAPSHOT?
>>>> 
>>>> If we branch off 2.1.x-branch and then roll master to 2.2.0-SNAPSHOT
>>>> immediately, we can merge any commits into master and mark them in Jira
>>>> with fix version 2.2.0. If we then get a bugfix that needs to go in e.g.
>>>> 2.1.1, we can merge it to master and cherry pick the commit back to
>>>> 2.1.x-branch, and update the fix version to both 2.2.0 and 2.1.1. This is
>>>> basically similar to how it worked for the 1.x-branch branches.
>>>> 
>>>> Why do we need 2.1-SNAPSHOT?
>>>> 
>>>> Den man. 19. aug. 2019 kl. 20.03 skrev Ethan Li <
>>> ethanopensource@gmail.com <mailto:ethanopensource@gmail.com> <mailto:ethanopensource@gmail.com <mailto:ethanopensource@gmail.com>>>:
>>>> 
>>>>> We don’t create 2.1.0 branch.
>>>>> 
>>>>> I was thinking (and have been doing) about creating a 2.1.x-branch
>>> before
>>>>> doing any thing release related.  Then we use 2.1.x-branch to release
>>>>> 2.1.0, and 2.1.1, etc.
>>>>> 
>>>>> When we create a 2.1.x-branch,  we move master to 2.2.x-branch. It’s a
>>>>> little different than what we did in the past. But it makes more sense
>>> as
>>>>> it follows semantic versioning more strictly.
>>>>> 
>>>>> 
>>>>> 
>>>>>> On Aug 19, 2019, at 12:53 PM, Stig Rohde Døssing <
>>> stigdoessing@gmail.com <mailto:stigdoessing@gmail.com>>
>>>>> wrote:
>>>>>> 
>>>>>> I would be fine with just freezing (non-critical) merges during the
>>>>>> release process. These mails are public, so it's easy for anyone to see
>>>>>> whether a release is in progress.
>>>>>> 
>>>>>> If we want to do merges while releases are going on, I think your
>>>>> proposal
>>>>>> of using a release branch is fine. I'm not sure I understand why we
>>> need
>>>>>> the 2.1-SNAPSHOT version though?
>>>>>> 
>>>>>> Let's say we create release branch 2.1.0-branch from master. We roll
>>> the
>>>>>> master version to 2.1.1-SNAPSHOT (for example) after the 2.1.0 branch
>>> is
>>>>>> created. We then get a bug fix that should go in 2.1.0. In this case we
>>>>>> should merge it to 2.1.0-branch, then merge 2.1.0-branch to master. In
>>>>> Jira
>>>>>> we mark it as going in 2.1.0.
>>>>>> 
>>>>>> We then get a PR that shouldn't be included in 2.1.0. We just merge it
>>> to
>>>>>> master, and mark it as 2.1.1 in Jira.
>>>>>> 
>>>>>> Finally once 2.1.0 is released, we merge 2.1.0-branch into master and
>>>>>> delete 2.1.0-branch.
>>>>>> 
>>>>>> Why is there a need to 2.1-SNAPSHOT?
>>>>>> 
>>>>>> Den man. 19. aug. 2019 kl. 18.15 skrev Ethan Li <
>>>>> ethanopensource@gmail.com <mailto:ethanopensource@gmail.com> <mailto:ethanopensource@gmail.com <mailto:ethanopensource@gmail.com>> <mailto:
>>> ethanopensource@gmail.com <mailto:ethanopensource@gmail.com> <mailto:ethanopensource@gmail.com <mailto:ethanopensource@gmail.com>>>>:
>>>>>> 
>>>>>>> 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, bu g 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 <mailto:ethanopensource@gmail.com>
>>> <mailto:ethanopensource@gmail.com <mailto: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> <
>>> https://github.com/apache/storm/pull/3106 <https://github.com/apache/storm/pull/3106>> <
>>>>>>> https://github.com/apache/storm/pull/3106 <https://github.com/apache/storm/pull/3106> <
>>> https://github.com/apache/storm/pull/3106 <https://github.com/apache/storm/pull/3106>> <
>>>>> https://github.com/apache/storm/pull/3106 <https://github.com/apache/storm/pull/3106> <
>>> 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>
>>> <mailto:ethanopensource@gmail.com <mailto:ethanopensource@gmail.com>>
>>>>> <mailto:ethanopensource@gmail.com <mailto:ethanopensource@gmail.com> <mailto:ethanopensource@gmail.com <mailto:ethanopensource@gmail.com>>>
>>>>>>> <mailto:ethanopensource@gmail.com <mailto:ethanopensource@gmail.com> <mailto:ethanopensource@gmail.com <mailto:ethanopensource@gmail.com>>
>>> <mailto:ethanopensource@gmail.com <mailto:ethanopensource@gmail.com> <mailto: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>
>>> <
>>> 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>
>>>> 
>>>>> <
>>>>> 
>>> 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>
>>> <
>>> 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>
>>>> 
>>>>>> 
>>>>>>> <
>>>>>>> 
>>>>> 
>>> 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>
>>> <
>>> 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>
>>>> 
>>>>> <
>>>>> 
>>> 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>
>>> <
>>> 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>
>>> <mailto:ethanopensource@gmail.com <mailto:ethanopensource@gmail.com>>
>>>>> <mailto:ethanopensource@gmail.com <mailto:ethanopensource@gmail.com> <mailto:ethanopensource@gmail.com <mailto:ethanopensource@gmail.com>>>
>>>>>>> <mailto:ethanopensource@gmail.com <mailto:ethanopensource@gmail.com> <mailto:ethanopensource@gmail.com <mailto:ethanopensource@gmail.com>>
>>> <mailto:ethanopensource@gmail.com <mailto:ethanopensource@gmail.com> <mailto: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>
>>> <
>>> 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>
>>>> 
>>>>> <
>>>>> 
>>> 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>
>>> <
>>> 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>
>>>> 
>>>>>> 
>>>>>>> <
>>>>>>> 
>>>>> 
>>> 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>
>>> <
>>> 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>
>>>> 
>>>>> <
>>>>> 
>>> 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>
>>> <
>>> 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>
>>> <mailto:ethanopensource@gmail.com <mailto:ethanopensource@gmail.com>>
>>>>> <mailto:ethanopensource@gmail.com <mailto:ethanopensource@gmail.com> <mailto:ethanopensource@gmail.com <mailto:ethanopensource@gmail.com>>>
>>>>>>> <mailto:ethanopensource@gmail.com <mailto:ethanopensource@gmail.com> <mailto:ethanopensource@gmail.com <mailto:ethanopensource@gmail.com>>
>>> <mailto:ethanopensource@gmail.com <mailto:ethanopensource@gmail.com> <mailto: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> <mailto:stigdoessing@gmail.com <mailto:stigdoessing@gmail.com>> <mailto:
>>> stigdoessing@gmail.com <mailto:stigdoessing@gmail.com> <mailto:stigdoessing@gmail.com <mailto:stigdoessing@gmail.com>>> <mailto:
>>>>> stigdoessing@gmail.com <mailto:stigdoessing@gmail.com> <mailto:stigdoessing@gmail.com <mailto:stigdoessing@gmail.com>> <mailto:
>>> stigdoessing@gmail.com <mailto:stigdoessing@gmail.com> <mailto:stigdoessing@gmail.com <mailto:stigdoessing@gmail.com>>>>> wrote:
>>>>>>>>>>>> 
>>>>>>>>>>>> Updated https://github.com/apache/storm/pull/3053 <https://github.com/apache/storm/pull/3053> <
>>> https://github.com/apache/storm/pull/3053 <https://github.com/apache/storm/pull/3053>> <
>>>>> https://github.com/apache/storm/pull/3053 <https://github.com/apache/storm/pull/3053> <
>>> https://github.com/apache/storm/pull/3053 <https://github.com/apache/storm/pull/3053>>> <
>>>>>>> https://github.com/apache/storm/pull/3053 <https://github.com/apache/storm/pull/3053> <
>>> https://github.com/apache/storm/pull/3053 <https://github.com/apache/storm/pull/3053>> <
>>>>> https://github.com/apache/storm/pull/3053 <https://github.com/apache/storm/pull/3053> <
>>> 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> <mailto:ethanopensource@gmail.com <mailto:ethanopensource@gmail.com>> <mailto:
>>> ethanopensource@gmail.com <mailto:ethanopensource@gmail.com> <mailto:ethanopensource@gmail.com <mailto:ethanopensource@gmail.com>>> <mailto:
>>>>> ethanopensource@gmail.com <mailto:ethanopensource@gmail.com> <mailto:ethanopensource@gmail.com <mailto:ethanopensource@gmail.com>> <mailto:
>>> ethanopensource@gmail.com <mailto:ethanopensource@gmail.com> <mailto: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> <mailto:ptgoetz@gmail.com <mailto:ptgoetz@gmail.com>>
>>>>> <mailto:ptgoetz@gmail.com <mailto:ptgoetz@gmail.com> <mailto:ptgoetz@gmail.com <mailto:ptgoetz@gmail.com>>>
>>>>>>> <mailto:ptgoetz@gmail.com <mailto:ptgoetz@gmail.com> <mailto:ptgoetz@gmail.com <mailto:ptgoetz@gmail.com>> <mailto:
>>> ptgoetz@gmail.com <mailto:ptgoetz@gmail.com> <mailto: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> <mailto:ethanopensource@gmail.com <mailto:ethanopensource@gmail.com>> <mailto:
>>> ethanopensource@gmail.com <mailto:ethanopensource@gmail.com> <mailto:ethanopensource@gmail.com <mailto:ethanopensource@gmail.com>>>
>>>>>>> <mailto:ethanopensource@gmail.com <mailto:ethanopensource@gmail.com> <mailto:ethanopensource@gmail.com <mailto:ethanopensource@gmail.com>>
>>> <mailto:ethanopensource@gmail.com <mailto:ethanopensource@gmail.com> <mailto: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://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://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://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://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://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://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://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>
>>>> 
>>>>> <
>>>>> 
>>> 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>
>>>> 
>>>>>> 
>>>>>>> <
>>>>>>> 
>>>>> 
>>> 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>
>>>> 
>>>>> <
>>>>> 
>>> 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>
>>>> 
>>>>>> 
>>>>>>>> 
>>>>>>>>>>>>> <
>>>>>>>>>>>>> 
>>>>>>> 
>>>>> 
>>> 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>
>>>> 
>>>>> <
>>>>> 
>>> 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>
>>>> 
>>>>>> 
>>>>>>> <
>>>>>>> 
>>>>> 
>>> 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>
>>>> 
>>>>> <
>>>>> 
>>> 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/>> <
>>>>> 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://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://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://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://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://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://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> <mailto:ethanopensource@gmail.com <mailto:ethanopensource@gmail.com>> <mailto:
>>> ethanopensource@gmail.com <mailto:ethanopensource@gmail.com> <mailto:ethanopensource@gmail.com <mailto:ethanopensource@gmail.com>>> <mailto:
>>>>> ethanopensource@gmail.com <mailto:ethanopensource@gmail.com> <mailto:ethanopensource@gmail.com <mailto:ethanopensource@gmail.com>> <mailto:
>>> ethanopensource@gmail.com <mailto:ethanopensource@gmail.com> <mailto: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> <mailto:stigdoessing@gmail.com <mailto:stigdoessing@gmail.com>> <mailto:
>>> stigdoessing@gmail.com <mailto:stigdoessing@gmail.com> <mailto:stigdoessing@gmail.com <mailto:stigdoessing@gmail.com>>> <mailto:
>>>>> stigdoessing@gmail.com <mailto:stigdoessing@gmail.com> <mailto:stigdoessing@gmail.com <mailto:stigdoessing@gmail.com>> <mailto:
>>> stigdoessing@gmail.com <mailto:stigdoessing@gmail.com> <mailto: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> <mailto:ethanopensource@gmail.com <mailto:ethanopensource@gmail.com>>
>>> <mailto:ethanopensource@gmail.com <mailto:ethanopensource@gmail.com> <mailto:ethanopensource@gmail.com <mailto:ethanopensource@gmail.com>>>
>>>>> <mailto:ethanopensource@gmail.com <mailto:ethanopensource@gmail.com> <mailto:ethanopensource@gmail.com <mailto:ethanopensource@gmail.com>>
>>> <mailto:ethanopensource@gmail.com <mailto:ethanopensource@gmail.com> <mailto: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> <mailto:stigdoessing@gmail.com <mailto:stigdoessing@gmail.com>> <mailto:
>>> stigdoessing@gmail.com <mailto:stigdoessing@gmail.com> <mailto:stigdoessing@gmail.com <mailto:stigdoessing@gmail.com>>> <mailto:
>>>>> stigdoessing@gmail.com <mailto:stigdoessing@gmail.com> <mailto:stigdoessing@gmail.com <mailto:stigdoessing@gmail.com>> <mailto:
>>> stigdoessing@gmail.com <mailto:stigdoessing@gmail.com> <mailto: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> <
>>> https://github.com/apache/storm/pull/3031 <https://github.com/apache/storm/pull/3031>> <
>>>>> https://github.com/apache/storm/pull/3031 <https://github.com/apache/storm/pull/3031> <
>>> https://github.com/apache/storm/pull/3031 <https://github.com/apache/storm/pull/3031>>> <
>>>>>>> https://github.com/apache/storm/pull/3031 <https://github.com/apache/storm/pull/3031> <
>>> https://github.com/apache/storm/pull/3031 <https://github.com/apache/storm/pull/3031>> <
>>>>> https://github.com/apache/storm/pull/3031 <https://github.com/apache/storm/pull/3031> <
>>> 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> <
>>> https://github.com/apache/storm/pull/3053 <https://github.com/apache/storm/pull/3053>> <
>>>>> https://github.com/apache/storm/pull/3053 <https://github.com/apache/storm/pull/3053> <
>>> https://github.com/apache/storm/pull/3053 <https://github.com/apache/storm/pull/3053>>> <
>>>>>>> https://github.com/apache/storm/pull/3053 <https://github.com/apache/storm/pull/3053> <
>>> https://github.com/apache/storm/pull/3053 <https://github.com/apache/storm/pull/3053>> <
>>>>> https://github.com/apache/storm/pull/3053 <https://github.com/apache/storm/pull/3053> <
>>> 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> <mailto:stigdoessing@gmail.com <mailto:stigdoessing@gmail.com>>
>>> <mailto:stigdoessing@gmail.com <mailto:stigdoessing@gmail.com> <mailto:stigdoessing@gmail.com <mailto:stigdoessing@gmail.com>>>
>>>>> <mailto:stigdoessing@gmail.com <mailto:stigdoessing@gmail.com> <mailto:stigdoessing@gmail.com <mailto:stigdoessing@gmail.com>> <mailto:
>>> stigdoessing@gmail.com <mailto:stigdoessing@gmail.com> <mailto: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> <
>>> https://github.com/apache/storm/pull/3053 <https://github.com/apache/storm/pull/3053>> <
>>>>> https://github.com/apache/storm/pull/3053 <https://github.com/apache/storm/pull/3053> <
>>> https://github.com/apache/storm/pull/3053 <https://github.com/apache/storm/pull/3053>>> <
>>>>>>> https://github.com/apache/storm/pull/3053 <https://github.com/apache/storm/pull/3053> <
>>> https://github.com/apache/storm/pull/3053 <https://github.com/apache/storm/pull/3053>> <
>>>>> https://github.com/apache/storm/pull/3053 <https://github.com/apache/storm/pull/3053> <
>>> 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> <mailto:
>>> ethanopensource@gmail.com <mailto:ethanopensource@gmail.com>> <mailto:ethanopensource@gmail.com <mailto:ethanopensource@gmail.com> <mailto:
>>> ethanopensource@gmail.com <mailto:ethanopensource@gmail.com>>>
>>>>> <mailto:ethanopensource@gmail.com <mailto:ethanopensource@gmail.com> <mailto:ethanopensource@gmail.com <mailto:ethanopensource@gmail.com>>
>>> <mailto:ethanopensource@gmail.com <mailto:ethanopensource@gmail.com> <mailto: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?>> <
>>>>> 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?>>> <
>>>>>>> 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?>> <
>>>>> 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?>>>>
>>>>>>>>>>>>> <
>>>>>>>>>>>>>>>>>>>>> 
>>>>>>> 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?>> <
>>>>> 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?>>> <
>>>>>>> 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?>> <
>>>>> 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> <mailto:ethanopensource@gmail.com <mailto:ethanopensource@gmail.com>> <mailto:
>>> ethanopensource@gmail.com <mailto:ethanopensource@gmail.com> <mailto:ethanopensource@gmail.com <mailto:ethanopensource@gmail.com>>> <mailto:
>>>>> ethanopensource@gmail.com <mailto:ethanopensource@gmail.com> <mailto:ethanopensource@gmail.com <mailto:ethanopensource@gmail.com>> <mailto:
>>> ethanopensource@gmail.com <mailto:ethanopensource@gmail.com> <mailto: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> <mailto:ptgoetz@gmail.com <mailto:ptgoetz@gmail.com>> <mailto:
>>> ptgoetz@gmail.com <mailto:ptgoetz@gmail.com> <mailto:ptgoetz@gmail.com <mailto:ptgoetz@gmail.com>>> <mailto:ptgoetz@gmail.com <mailto:ptgoetz@gmail.com>
>>> <mailto:ptgoetz@gmail.com <mailto:ptgoetz@gmail.com>>
>>>>> <mailto:ptgoetz@gmail.com <mailto:ptgoetz@gmail.com> <mailto: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> <mailto:ethanopensource@gmail.com <mailto:ethanopensource@gmail.com>>
>>> <mailto:ethanopensource@gmail.com <mailto:ethanopensource@gmail.com> <mailto:ethanopensource@gmail.com <mailto:ethanopensource@gmail.com>>>
>>>>> <mailto:ethanopensource@gmail.com <mailto:ethanopensource@gmail.com> <mailto:ethanopensource@gmail.com <mailto:ethanopensource@gmail.com>>
>>> <mailto:ethanopensource@gmail.com <mailto:ethanopensource@gmail.com> <mailto: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>
>>>> 
>>>>> <
>>>>> 
>>> 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
>>>>> <
>>>>> 
>>> 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