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 <[email protected]> > 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 <[email protected]>: > >> 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 <[email protected]> >> 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 < >> [email protected]>: >>> >>>> 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 <[email protected]> >> 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 <[email protected] <mailto: >>>> [email protected]>> 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 <[email protected] <mailto: >>>> [email protected]>> 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 < >> [email protected] >>>> <mailto:[email protected]>>: >>>>>>>>> >>>>>>>>>> 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 < >> [email protected]> >>>>>>>>>> wrote: >>>>>>>>>>>> >>>>>>>>>>>> Yes thanks. >>>>>>>>>>>> >>>>>>>>>>>>> On Aug 7, 2019, at 10:39 AM, Stig Rohde Døssing < >>>>>>>>>> [email protected]> 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 < >>>>>>>>>> [email protected]>: >>>>>>>>>>>>> >>>>>>>>>>>>>> I got my pgp key signed by Bryan W. Call <[email protected] >>>> <mailto: >>>>>>>>>>>>>> [email protected]>> (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 < >>>>>>>>>> [email protected]> >>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Thanks Ethan, yes 2.1.0 makes sense. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Den man. 29. jul. 2019 kl. 23.43 skrev Ethan Li < >>>>>>>>>>>>>> [email protected]>: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> 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 < >> [email protected] >>>>> >>>>>>>>>> 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 < >>>>>>>>>> [email protected]> >>>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Thanks Stig. I will look into it. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> On Jul 26, 2019, at 3:06 PM, Stig Rohde Døssing < >>>>>>>>>>>>>>>> [email protected]> >>>>>>>>>>>>>>>>>> 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 < >>>>>>>>>>>>>>>>>> [email protected]>: >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> 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 < >>>>>>>>>>>>>>>>>> [email protected]> >>>>>>>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> Sounds great, thanks Ethan. >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> Den fre. 26. jul. 2019 kl. 19.16 skrev Ethan Li < >>>>>>>>>>>>>>>>>>>> [email protected]>: >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> 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 < >>>>>>>>>>>>>>>>>>>> [email protected]> >>>>>>>>>>>>>>>>>>>>>> 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? >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>> >>>>> >>>> >>>> >> >>
