storm-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ethan Li <ethanopensou...@gmail.com>
Subject Re: [DISCUSS] Next 2.x release
Date Tue, 13 Aug 2019 16:15:41 GMT
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 <ethanopensource@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 <stigdoessing@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 <ethanopensource@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 <stigdoessing@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 <
>>>> stigdoessing@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 <
>>> ethanopensource@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 <ethanopensource@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 <ptgoetz@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 <ethanopensource@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 <ethanopensource@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 <ptgoetz@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 <
>>>>>> stigdoessing@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 <
>>>>>> ethanopensource@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 <
>>>>>> stigdoessing@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 <
>>>>>>>>>>>>> ethanopensource@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 <
>>>>>> ethanopensource@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 <dagit@apache.org
>>>>>> <mailto:
>>>>>>>>>>>>>>> dagit@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 <dagit@apache.org
>>>>>> <mailto:
>>>>>>>>>>>>>>> dagit@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 <
>>>>>>>>>>>>> dagit@apache.org
>>>>>>>>>>>>>>> <mailto:dagit@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 <
>>>>>>>>>>>>> ethanopensource@gmail.com>
>>>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>> Yes thanks.
>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>> On Aug 7, 2019, at 10:39 AM, Stig Rohde Døssing <
>>>>>>>>>>>>>>>>>>>>> stigdoessing@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 <
>>>>>>>>>>>>>>>>>>>>> ethanopensource@gmail.com>:
>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>> I got my pgp key signed by Bryan W. Call <
>>>>>> bcall@apache.org
>>>>>>>>>>>>>>> <mailto:
>>>>>>>>>>>>>>>>>>>>>>>>> bcall@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 <
>>>>>>>>>>>>>>>>>>>>> stigdoessing@gmail.com>
>>>>>>>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>> Thanks Ethan, yes 2.1.0 makes sense.
>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>> Den man. 29. jul. 2019 kl. 23.43 skrev Ethan Li <
>>>>>>>>>>>>>>>>>>>>>>>>> ethanopensource@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 <
>>>>>>>>>>>>> hmclouro@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 <
>>>>>>>>>>>>>>>>>>>>> ethanopensource@gmail.com>
>>>>>>>>>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Thanks Stig. I will look into it.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On Jul 26, 2019, at 3:06 PM, Stig Rohde
>>> Døssing <
>>>>>>>>>>>>>>>>>>>>>>>>>>> stigdoessing@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 <
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> ethanopensource@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 <
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> stigdoessing@gmail.com>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Sounds great, thanks Ethan.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Den fre. 26. jul. 2019 kl. 19.16 skrev Ethan
>>>>>> Li <
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> ethanopensource@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 <
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> stigdoessing@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?
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>> 
>>>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>> 
>>>>>>>> 
>>>>>>> 
>>>>>> 
>>>>>> 
>>> 
>>> 
> 


Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message