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 20:01:36 GMT
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> 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>
>> 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
>>>>>>> 
>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>> 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