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:15:48 GMT
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> 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>
>>>> 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