storm-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "P. Taylor Goetz" <ptgo...@gmail.com>
Subject Re: [DISCUSS] Next 2.x release
Date Tue, 13 Aug 2019 16:19:46 GMT
Those can be safely deleted.

-Taylor

> On Aug 13, 2019, at 12:15 PM, Ethan Li <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://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/>
> 
> Just want to be absolutely sure about this. Thanks.
> 
>> On Aug 13, 2019, at 10:56 AM, Ethan Li <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> 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>:
>>> 
>>>> 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>
>>>> wrote:
>>>>> 
>>>>> Oops, sorry that's not right. The license plugin setup was disabled in
>>>>> 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,
>>>>> 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>:
>>>>> 
>>>>>> There's a script that can help you do it in
>>>>>> 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
>>>>>>> :
>>>>>> 
>>>>>>> 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?> 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>
>>>>>>> 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>
>>>>>>> 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>
>>>>>>> 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
>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> 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
View raw message