I would be fine with just freezing (non-critical) merges during the release process. These mails are public, so it's easy for anyone to see whether a release is in progress.
If we want to do merges while releases are going on, I think your proposal of using a release branch is fine. I'm not sure I understand why we need the 2.1-SNAPSHOT version though? Let's say we create release branch 2.1.0-branch from master. We roll the master version to 2.1.1-SNAPSHOT (for example) after the 2.1.0 branch is created. We then get a bug fix that should go in 2.1.0. In this case we should merge it to 2.1.0-branch, then merge 2.1.0-branch to master. In Jira we mark it as going in 2.1.0. We then get a PR that shouldn't be included in 2.1.0. We just merge it to master, and mark it as 2.1.1 in Jira. Finally once 2.1.0 is released, we merge 2.1.0-branch into master and delete 2.1.0-branch. Why is there a need to 2.1-SNAPSHOT? Den man. 19. aug. 2019 kl. 18.15 skrev Ethan Li <ethanopensou...@gmail.com>: > Many issues came up while I was preparing for 2.1.0 release. Freezing > merge until the release is done is not practical. So I am proposing: > > 1. Once we decide to make a release, we create a new branch based on > master and start release process. > 2. During the new process, master is still open for backwards > compatibility commits, including new features, bu g fixes, etc. > 3. Only bug fixes will be merged to the new branch and we need to restart > the release process to include the bug fixes. > 4. To avoid too much confusion on pom versions when we merge new commits > during the release process, we should use less concrete version. For > example, in 2.1.x-branch, the pom version should be 2.1-SNAPSHOT, instead > of 2.1.0-SNAPSHOT. > > For example, > > Let’s say we have a new branch 2.1.x-branch, the pom version is > 2.1.0-SNAPSHOT. We start the release process and after running the mvn > release:prepare -Pxxx command, the pom version changes to 2.1.1-SNAPSHOT, > and before that a git tag v2.1.0 is created. Now if there is a bug fix we > have to merge in, so we merge in and it’s actually merged in to > 2.1.1-SNAPSHOT at this point if we don’t manually revert the pom version, > which can be confusing. We can avoid this problem by just using > 2.1-SNAPSHOT as the pom version. So it doesn’t have to change. > > Please let me know if there is any potential risk for doing this. > > Thanks > Ethan > > > On Aug 19, 2019, at 10:25 AM, Ethan Li <ethanopensou...@gmail.com> > wrote: > > > > The pull request for the fix is > https://github.com/apache/storm/pull/3106 < > https://github.com/apache/storm/pull/3106> > > > >> On Aug 19, 2019, at 10:15 AM, Ethan Li <ethanopensou...@gmail.com > <mailto:ethanopensou...@gmail.com>> wrote: > >> > >> So I was preparing for a new release candidate i.e. rc3. I can build it > from source without any problem. Then I set up a standalone cluster and > submitted a WordCountTopology. The workers kept restarting because of > >> > >> > >> 2019-08-19 15:09:49.635 o.a.s.t.ShellBolt Thread-30 [ERROR] Halting > process: ShellBolt died. Command: [python, splitsentence.py], ProcessInfo > pid:3756, name:split exitCode:-1, errorString: > >> java.lang.IllegalArgumentException: command sync is not supported > >> at > org.apache.storm.task.ShellBolt$BoltReaderRunnable.run(ShellBolt.java:366) > [storm-client-2.1.0.jar:2.1.0] > >> at java.lang.Thread.run(Thread.java:748) [?:1.8.0_181] > >> 2019-08-19 15:09:49.635 o.a.s.e.e.ReportError Thread-30 [ERROR] Error > >> java.lang.IllegalArgumentException: command sync is not supported > >> at > org.apache.storm.task.ShellBolt$BoltReaderRunnable.run(ShellBolt.java:366) > [storm-client-2.1.0.jar:2.1.0] > >> at java.lang.Thread.run(Thread.java:748) [?:1.8.0_181] > >> 2019-08-19 15:09:49.636 o.a.s.t.ShellBolt Thread-28 [ERROR] Halting > process: ShellBolt died. Command: [python, splitsentence.py], ProcessInfo > pid:3755, name:split exitCode:-1, errorString: > >> java.lang.IllegalArgumentException: command sync is not supported > >> at > org.apache.storm.task.ShellBolt$BoltReaderRunnable.run(ShellBolt.java:366) > [storm-client-2.1.0.jar:2.1.0] > >> at java.lang.Thread.run(Thread.java:748) [?:1.8.0_181] > >> 2019-08-19 15:09:49.637 o.a.s.e.e.ReportError Thread-28 [ERROR] Error > >> java.lang.IllegalArgumentException: command sync is not supported > >> at > org.apache.storm.task.ShellBolt$BoltReaderRunnable.run(ShellBolt.java:366) > [storm-client-2.1.0.jar:2.1.0] > >> at java.lang.Thread.run(Thread.java:748) [?:1.8.0_181] > >> > >> > >> > >> > https://github.com/apache/storm/blob/master/storm-client/src/jvm/org/apache/storm/task/ShellBolt.java#L365-L367 > < > https://github.com/apache/storm/blob/master/storm-client/src/jvm/org/apache/storm/task/ShellBolt.java#L365-L367> > I believe we shouldn’t throw exceptions here. > >> > >> Will make a pull request to fix it. > >> > >> > >> > >>> On Aug 14, 2019, at 11:11 PM, Ethan Li <ethanopensou...@gmail.com > <mailto:ethanopensou...@gmail.com>> wrote: > >>> > >>> Hi Taylor, > >>> > >>> Mostly I was able to follow the doc > https://github.com/apache/storm/blob/master/RELEASING.md#setting-up-a-vote > < > https://github.com/apache/storm/blob/master/RELEASING.md#setting-up-a-vote>, > except: > >>> > >>> For Step 1, I used the following command as suggested. > >>> mvn release:prepare -P dist,rat,externals,examples > >>> mvn release:perform -P dist,rat,externals,examples > >>> > >>> > >>> For Step3, I had to run "git checkout tags/v2.1.0 -b v2.1.0” so that > I can run “mvn package” for storm-dist/binary and storm-dist/source based > on v2.1.0. Otherwise if I run “mvn package” on 2.1.x-branch, it will fail > because the pom version is “2.1.x-SNAPSHOT”. > >>> > >>> Then I find packages in storm-dist/binary/final-package/target and > storm-dist/source/target, sign them, generate checksum and copy them to svn. > >>> > >>> I think there are something I should do. But please let me know if I > was doing something wrong. I will also update the doc after the release > is complete. Thank you very much! > >>> > >>> Ethan > >>> > >>> > >>>> On Aug 14, 2019, at 12:24 PM, Ethan Li <ethanopensou...@gmail.com > <mailto:ethanopensou...@gmail.com>> wrote: > >>>> > >>>> I am continuing for another release candidate since the pr is merged. > >>>> > >>>>> On Aug 13, 2019, at 11:58 AM, Stig Rohde Døssing < > stigdoess...@gmail.com <mailto:stigdoess...@gmail.com>> wrote: > >>>>> > >>>>> Updated https://github.com/apache/storm/pull/3053 < > https://github.com/apache/storm/pull/3053> so we don't have > >>>>> org.apache.storm artifacts in the DEPENDENCY-LICENSES file. It's > ready for > >>>>> review if someone wants to look at it. > >>>>> > >>>>> Den tir. 13. aug. 2019 kl. 18.21 skrev Ethan Li < > ethanopensou...@gmail.com <mailto:ethanopensou...@gmail.com>>: > >>>>> > >>>>>> Thank you, Taylor. Will delete them. > >>>>>> > >>>>>>> On Aug 13, 2019, at 11:19 AM, P. Taylor Goetz <ptgo...@gmail.com > <mailto:ptgo...@gmail.com>> wrote: > >>>>>>> > >>>>>>> Those can be safely deleted. > >>>>>>> > >>>>>>> -Taylor > >>>>>>> > >>>>>>>> On Aug 13, 2019, at 12:15 PM, Ethan Li <ethanopensou...@gmail.com > <mailto: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://dist.apache.org/repos/dist/dev/storm < > https://dist.apache.org/repos/dist/dev/storm>> ? > >>>>>>>> > >>>>>>>> > >>>>>> > https://github.com/apache/storm/blob/master/RELEASING.md#cleaning-up-if-the-vote-fails > < > https://github.com/apache/storm/blob/master/RELEASING.md#cleaning-up-if-the-vote-fails > > > >>>>>> < > >>>>>> > https://github.com/apache/storm/blob/master/RELEASING.md#cleaning-up-if-the-vote-fails > < > https://github.com/apache/storm/blob/master/RELEASING.md#cleaning-up-if-the-vote-fails > >> > >>>>>> says we do. But we have a lot of rc in > >>>>>> https://dist.apache.org/repos/dist/dev/storm/ < > https://dist.apache.org/repos/dist/dev/storm/> < > >>>>>> https://dist.apache.org/repos/dist/dev/storm/ < > https://dist.apache.org/repos/dist/dev/storm/>> > >>>>>>>> > >>>>>>>> Just want to be absolutely sure about this. Thanks. > >>>>>>>> > >>>>>>>>> On Aug 13, 2019, at 10:56 AM, Ethan Li < > ethanopensou...@gmail.com <mailto: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 <mailto: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 <mailto: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 <mailto:stigdoess...@gmail.com>> > >>>>>>>>>>> wrote: > >>>>>>>>>>>> > >>>>>>>>>>>> Oops, sorry that's not right. The license plugin setup was > disabled > >>>>>> in > >>>>>>>>>>>> https://github.com/apache/storm/pull/3031 < > https://github.com/apache/storm/pull/3031> due to a bug in the > >>>>>> license > >>>>>>>>>>>> plugin. It is added back in > >>>>>> https://github.com/apache/storm/pull/3053 < > https://github.com/apache/storm/pull/3053>, > >>>>>>>>>>>> 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 <mailto:stigdoess...@gmail.com>>: > >>>>>>>>>>>> > >>>>>>>>>>>>> There's a script that can help you do it in > >>>>>>>>>>>>> https://github.com/apache/storm/pull/3053 < > https://github.com/apache/storm/pull/3053>. 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 <mailto: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?> > >>>>>> < > >>>>>>>>>>>>>> > 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 <mailto: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 <mailto: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 <mailto: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 > > > >>>>>>>>>>>>>> < > >>>>>>>>>>>>>> > >>>>>>>>>>> > >>>>>> > 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? > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>> > >>>>>>>> > >>>>>>> > >>>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>> > >>> > >> > > > >
