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 <[email protected]> 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 <[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? >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>> >>>>>> >>>>> >>>>> >>> >>> >
