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?
|