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 Mon, 19 Aug 2019 15:25:26 GMT
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 <ethanopensource@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 <ethanopensource@gmail.com <mailto:ethanopensource@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 <ethanopensource@gmail.com <mailto:ethanopensource@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 <stigdoessing@gmail.com <mailto:stigdoessing@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 <ethanopensource@gmail.com <mailto:ethanopensource@gmail.com>>:
>>>> 
>>>>> Thank you, Taylor. Will delete them.
>>>>> 
>>>>>> On Aug 13, 2019, at 11:19 AM, P. Taylor Goetz <ptgoetz@gmail.com <mailto:ptgoetz@gmail.com>> wrote:
>>>>>> 
>>>>>> Those can be safely deleted.
>>>>>> 
>>>>>> -Taylor
>>>>>> 
>>>>>>> On Aug 13, 2019, at 12:15 PM, Ethan Li <ethanopensource@gmail.com <mailto:ethanopensource@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 <ethanopensource@gmail.com <mailto: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 <mailto: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 <mailto: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 <mailto:stigdoessing@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 <
>>>>>>>>>>> stigdoessing@gmail.com <mailto:stigdoessing@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 <
>>>>>>>>>> ethanopensource@gmail.com <mailto: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? <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 <mailto: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 <mailto: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 <mailto: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>
>>>>>>>>>>>>> <
>>>>>>>>>>>>> 
>>>>>>>>>> 
>>>>> 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