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? >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>> >>>>> >>> >> >
