Updated 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 <ethanopensou...@gmail.com>: > Thank you, Taylor. Will delete them. > > > On Aug 13, 2019, at 11:19 AM, P. Taylor Goetz <ptgo...@gmail.com> wrote: > > > > Those can be safely deleted. > > > > -Taylor > > > >> On Aug 13, 2019, at 12:15 PM, Ethan Li <ethanopensou...@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 <ethanopensou...@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 < > stigdoess...@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 < > ethanopensou...@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 < > stigdoess...@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 < > >>>>>> stigdoess...@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 < > >>>>> ethanopensou...@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 <ethanopensou...@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 <ptgo...@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 < > ethanopensou...@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 < > ethanopensou...@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 < > ptgo...@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 < > >>>>>>>> stigdoess...@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 < > >>>>>>>> ethanopensou...@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 < > >>>>>>>> stigdoess...@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 < > >>>>>>>>>>>>>>> ethanopensou...@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 < > >>>>>>>> ethanopensou...@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 < > da...@apache.org > >>>>>>>> <mailto: > >>>>>>>>>>>>>>>>> da...@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 < > da...@apache.org > >>>>>>>> <mailto: > >>>>>>>>>>>>>>>>> da...@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 < > >>>>>>>>>>>>>>> da...@apache.org > >>>>>>>>>>>>>>>>> <mailto:da...@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 < > >>>>>>>>>>>>>>> ethanopensou...@gmail.com> > >>>>>>>>>>>>>>>>>>>>>>> wrote: > >>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>> Yes thanks. > >>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>> On Aug 7, 2019, at 10:39 AM, Stig Rohde Døssing > < > >>>>>>>>>>>>>>>>>>>>>>> stigdoess...@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 < > >>>>>>>>>>>>>>>>>>>>>>> ethanopensou...@gmail.com>: > >>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>> I got my pgp key signed by Bryan W. Call < > >>>>>>>> bc...@apache.org > >>>>>>>>>>>>>>>>> <mailto: > >>>>>>>>>>>>>>>>>>>>>>>>>>> bc...@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 < > >>>>>>>>>>>>>>>>>>>>>>> stigdoess...@gmail.com> > >>>>>>>>>>>>>>>>>>>>>>>>>>> wrote: > >>>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>>> Thanks Ethan, yes 2.1.0 makes sense. > >>>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>>> Den man. 29. jul. 2019 kl. 23.43 skrev Ethan > Li < > >>>>>>>>>>>>>>>>>>>>>>>>>>> ethanopensou...@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 < > >>>>>>>>>>>>>>> hmclo...@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 < > >>>>>>>>>>>>>>>>>>>>>>> ethanopensou...@gmail.com> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>> wrote: > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Thanks Stig. I will look into it. > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On Jul 26, 2019, at 3:06 PM, Stig Rohde > >>>>> Døssing < > >>>>>>>>>>>>>>>>>>>>>>>>>>>>> stigdoess...@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 < > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> ethanopensou...@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 < > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> stigdoess...@gmail.com> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> wrote: > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Sounds great, thanks Ethan. > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Den fre. 26. jul. 2019 kl. 19.16 skrev > Ethan > >>>>>>>> Li < > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> ethanopensou...@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 < > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> stigdoess...@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? > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>> > >>>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>> > >>>>> > >>> > >> > > > > > > >
