Re: Release Planning for 1.1.1 and others?
Those some of the one’s I’ve been tracking for 1.1.1. I’ll do another run through JIRA to see if there’s anything else pending that needs to be included. I would encourage others to do so as well. -Taylor > On Jul 18, 2017, at 2:27 PM, Hugo Da Cruz Louro> wrote: > > Hi Jungtaek, > > Currently there are 2 critical bugs and no blocker bugs. > > https://issues.apache.org/jira/browse/STORM-2342- I still need to > investigate it. It may or may not be a bug. It is a bit surprising that such > basic functionality is not working. > https://issues.apache.org/jira/browse/STORM-2554- it has a pull request > pending review since 06/14/2017 > > Thanks, > Hugo > > On Jul 18, 2017, at 6:26 AM, Stig Rohde Døssing > > wrote: > > I think a month seems realistic, yes. > > Thanks for clarifying when it is okay to skip the waiting period. > > 2017-07-18 13:44 GMT+02:00 Jungtaek Lim > >: > > Thanks for following up Stig. > > According to your explanation, only a few issues are left for bug fix. I > feel they could be resolved around a month, and then we can track them as > epic issue from now on, and release once they're resolved. Make sense? > > Btw, if my understanding is right, you don't need to wait for 24hr to merge > #2221 (against 1.x-branch) given that #2152 (against master) is merged with > respecting bylaw rule, and difference of two PRs are small enough. > Accepting changes should follow bylaws, but porting back accepted changes > are up to the committer (normally merger). Committers even could apply hot > fix during merge phase if the patch couldn't be applied to other branches > as well, and we don't need another PRs for that. > > Thanks, > Jungtaek Lim (HeartSaVioR) > > 2017년 7월 18일 (화) 오후 8:22, Stig Rohde Døssing > >님이 > 작성: > > Hi Jungtaek, > > I think we're not too far off for most of the issues I'm aware of. > > I'd like to get some fixes around topic compaction ( > https://github.com/apache/storm/pull/2221 and > https://github.com/apache/storm/pull/2217) in for 1.1.1. They should be > mergeable once the 24 hour period has passed. I think it would also be > good > to get the maxUncommittedOffsets limit enforcement ( > https://github.com/apache/storm/pull/2156) looked at, since it shouldn't > require API changes and is a bugfix. Following 2156 and related to the > two > other PRs, there's also https://issues.apache.org/jira/browse/STORM-2546 > which I think we should consider fixing. It's waiting for PR 2156 to be > stabilized, but is hopefully an easy fix. See > > https://issues.apache.org/jira/browse/STORM-2343? > focusedCommentId=16044785=com.atlassian.jira. > plugin.system.issuetabpanels:comment-tabpanel#comment-16044785 > for the discussion. > > For 1.2.0, I think we should get in the KafkaSpoutConfig API changes and > deprecations (https://github.com/apache/storm/pull/2215) and a 1.x > version > of the manual partition assignment bugfix ( > https://github.com/apache/storm/pull/2150). > > 2017-07-17 11:25 GMT+02:00 Jungtaek Lim > >: > > Hi devs, > > We released Storm 1.1.0 at the late March, and we didn't have short > plan > for next release. > (We discussed Storm 2.0.0, and I think we're getting closer, a bit > slowly > but steady.) > > While we still have some issues and pull requests for > storm-kafka-client > which I think should be included to 1.0.1, but maybe we can start > planning > 1.1.1, having epic issue for release as we did for prior releases, and > also > other versions as well (1.2.0 or 2.0.0). > > Unless I'm missing something, looks like there're no critical bugs > except > storm-kafka-client for 1.1.1 candidate. So I think we could roll out > 1.1.1 > fairly soon after sorting out current issue on storm-kafka-client. I'm > not > familiar with storm-kafka-client module hence I'd like to rely on Hugo > or > Stig or other committers/contributors to sort out, but may spend some > time > to be familiar and participate if its progress is going to be slow. > > Looking forward to hear your opinions. > > Thanks, > Jungtaek Lim (HeartSaVioR) > > > >
Re: Release Planning for 1.1.1 and others?
Hi Jungtaek, Currently there are 2 critical bugs and no blocker bugs. https://issues.apache.org/jira/browse/STORM-2342- I still need to investigate it. It may or may not be a bug. It is a bit surprising that such basic functionality is not working. https://issues.apache.org/jira/browse/STORM-2554- it has a pull request pending review since 06/14/2017 Thanks, Hugo On Jul 18, 2017, at 6:26 AM, Stig Rohde Døssing> wrote: I think a month seems realistic, yes. Thanks for clarifying when it is okay to skip the waiting period. 2017-07-18 13:44 GMT+02:00 Jungtaek Lim >: Thanks for following up Stig. According to your explanation, only a few issues are left for bug fix. I feel they could be resolved around a month, and then we can track them as epic issue from now on, and release once they're resolved. Make sense? Btw, if my understanding is right, you don't need to wait for 24hr to merge #2221 (against 1.x-branch) given that #2152 (against master) is merged with respecting bylaw rule, and difference of two PRs are small enough. Accepting changes should follow bylaws, but porting back accepted changes are up to the committer (normally merger). Committers even could apply hot fix during merge phase if the patch couldn't be applied to other branches as well, and we don't need another PRs for that. Thanks, Jungtaek Lim (HeartSaVioR) 2017년 7월 18일 (화) 오후 8:22, Stig Rohde Døssing >님이 작성: Hi Jungtaek, I think we're not too far off for most of the issues I'm aware of. I'd like to get some fixes around topic compaction ( https://github.com/apache/storm/pull/2221 and https://github.com/apache/storm/pull/2217) in for 1.1.1. They should be mergeable once the 24 hour period has passed. I think it would also be good to get the maxUncommittedOffsets limit enforcement ( https://github.com/apache/storm/pull/2156) looked at, since it shouldn't require API changes and is a bugfix. Following 2156 and related to the two other PRs, there's also https://issues.apache.org/jira/browse/STORM-2546 which I think we should consider fixing. It's waiting for PR 2156 to be stabilized, but is hopefully an easy fix. See https://issues.apache.org/jira/browse/STORM-2343? focusedCommentId=16044785=com.atlassian.jira. plugin.system.issuetabpanels:comment-tabpanel#comment-16044785 for the discussion. For 1.2.0, I think we should get in the KafkaSpoutConfig API changes and deprecations (https://github.com/apache/storm/pull/2215) and a 1.x version of the manual partition assignment bugfix ( https://github.com/apache/storm/pull/2150). 2017-07-17 11:25 GMT+02:00 Jungtaek Lim >: Hi devs, We released Storm 1.1.0 at the late March, and we didn't have short plan for next release. (We discussed Storm 2.0.0, and I think we're getting closer, a bit slowly but steady.) While we still have some issues and pull requests for storm-kafka-client which I think should be included to 1.0.1, but maybe we can start planning 1.1.1, having epic issue for release as we did for prior releases, and also other versions as well (1.2.0 or 2.0.0). Unless I'm missing something, looks like there're no critical bugs except storm-kafka-client for 1.1.1 candidate. So I think we could roll out 1.1.1 fairly soon after sorting out current issue on storm-kafka-client. I'm not familiar with storm-kafka-client module hence I'd like to rely on Hugo or Stig or other committers/contributors to sort out, but may spend some time to be familiar and participate if its progress is going to be slow. Looking forward to hear your opinions. Thanks, Jungtaek Lim (HeartSaVioR)
Re: Release Planning for 1.1.1 and others?
I think a month seems realistic, yes. Thanks for clarifying when it is okay to skip the waiting period. 2017-07-18 13:44 GMT+02:00 Jungtaek Lim: > Thanks for following up Stig. > > According to your explanation, only a few issues are left for bug fix. I > feel they could be resolved around a month, and then we can track them as > epic issue from now on, and release once they're resolved. Make sense? > > Btw, if my understanding is right, you don't need to wait for 24hr to merge > #2221 (against 1.x-branch) given that #2152 (against master) is merged with > respecting bylaw rule, and difference of two PRs are small enough. > Accepting changes should follow bylaws, but porting back accepted changes > are up to the committer (normally merger). Committers even could apply hot > fix during merge phase if the patch couldn't be applied to other branches > as well, and we don't need another PRs for that. > > Thanks, > Jungtaek Lim (HeartSaVioR) > > 2017년 7월 18일 (화) 오후 8:22, Stig Rohde Døssing 님이 > 작성: > > > Hi Jungtaek, > > > > I think we're not too far off for most of the issues I'm aware of. > > > > I'd like to get some fixes around topic compaction ( > > https://github.com/apache/storm/pull/2221 and > > https://github.com/apache/storm/pull/2217) in for 1.1.1. They should be > > mergeable once the 24 hour period has passed. I think it would also be > good > > to get the maxUncommittedOffsets limit enforcement ( > > https://github.com/apache/storm/pull/2156) looked at, since it shouldn't > > require API changes and is a bugfix. Following 2156 and related to the > two > > other PRs, there's also https://issues.apache.org/jira/browse/STORM-2546 > > which I think we should consider fixing. It's waiting for PR 2156 to be > > stabilized, but is hopefully an easy fix. See > > > > https://issues.apache.org/jira/browse/STORM-2343? > focusedCommentId=16044785=com.atlassian.jira. > plugin.system.issuetabpanels:comment-tabpanel#comment-16044785 > > for the discussion. > > > > For 1.2.0, I think we should get in the KafkaSpoutConfig API changes and > > deprecations (https://github.com/apache/storm/pull/2215) and a 1.x > version > > of the manual partition assignment bugfix ( > > https://github.com/apache/storm/pull/2150). > > > > 2017-07-17 11:25 GMT+02:00 Jungtaek Lim : > > > > > Hi devs, > > > > > > We released Storm 1.1.0 at the late March, and we didn't have short > plan > > > for next release. > > > (We discussed Storm 2.0.0, and I think we're getting closer, a bit > slowly > > > but steady.) > > > > > > While we still have some issues and pull requests for > storm-kafka-client > > > which I think should be included to 1.0.1, but maybe we can start > > planning > > > 1.1.1, having epic issue for release as we did for prior releases, and > > also > > > other versions as well (1.2.0 or 2.0.0). > > > > > > Unless I'm missing something, looks like there're no critical bugs > except > > > storm-kafka-client for 1.1.1 candidate. So I think we could roll out > > 1.1.1 > > > fairly soon after sorting out current issue on storm-kafka-client. I'm > > not > > > familiar with storm-kafka-client module hence I'd like to rely on Hugo > or > > > Stig or other committers/contributors to sort out, but may spend some > > time > > > to be familiar and participate if its progress is going to be slow. > > > > > > Looking forward to hear your opinions. > > > > > > Thanks, > > > Jungtaek Lim (HeartSaVioR) > > > > > >
Re: Release Planning for 1.1.1 and others?
Thanks for following up Stig. According to your explanation, only a few issues are left for bug fix. I feel they could be resolved around a month, and then we can track them as epic issue from now on, and release once they're resolved. Make sense? Btw, if my understanding is right, you don't need to wait for 24hr to merge #2221 (against 1.x-branch) given that #2152 (against master) is merged with respecting bylaw rule, and difference of two PRs are small enough. Accepting changes should follow bylaws, but porting back accepted changes are up to the committer (normally merger). Committers even could apply hot fix during merge phase if the patch couldn't be applied to other branches as well, and we don't need another PRs for that. Thanks, Jungtaek Lim (HeartSaVioR) 2017년 7월 18일 (화) 오후 8:22, Stig Rohde Døssing님이 작성: > Hi Jungtaek, > > I think we're not too far off for most of the issues I'm aware of. > > I'd like to get some fixes around topic compaction ( > https://github.com/apache/storm/pull/2221 and > https://github.com/apache/storm/pull/2217) in for 1.1.1. They should be > mergeable once the 24 hour period has passed. I think it would also be good > to get the maxUncommittedOffsets limit enforcement ( > https://github.com/apache/storm/pull/2156) looked at, since it shouldn't > require API changes and is a bugfix. Following 2156 and related to the two > other PRs, there's also https://issues.apache.org/jira/browse/STORM-2546 > which I think we should consider fixing. It's waiting for PR 2156 to be > stabilized, but is hopefully an easy fix. See > > https://issues.apache.org/jira/browse/STORM-2343?focusedCommentId=16044785=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16044785 > for the discussion. > > For 1.2.0, I think we should get in the KafkaSpoutConfig API changes and > deprecations (https://github.com/apache/storm/pull/2215) and a 1.x version > of the manual partition assignment bugfix ( > https://github.com/apache/storm/pull/2150). > > 2017-07-17 11:25 GMT+02:00 Jungtaek Lim : > > > Hi devs, > > > > We released Storm 1.1.0 at the late March, and we didn't have short plan > > for next release. > > (We discussed Storm 2.0.0, and I think we're getting closer, a bit slowly > > but steady.) > > > > While we still have some issues and pull requests for storm-kafka-client > > which I think should be included to 1.0.1, but maybe we can start > planning > > 1.1.1, having epic issue for release as we did for prior releases, and > also > > other versions as well (1.2.0 or 2.0.0). > > > > Unless I'm missing something, looks like there're no critical bugs except > > storm-kafka-client for 1.1.1 candidate. So I think we could roll out > 1.1.1 > > fairly soon after sorting out current issue on storm-kafka-client. I'm > not > > familiar with storm-kafka-client module hence I'd like to rely on Hugo or > > Stig or other committers/contributors to sort out, but may spend some > time > > to be familiar and participate if its progress is going to be slow. > > > > Looking forward to hear your opinions. > > > > Thanks, > > Jungtaek Lim (HeartSaVioR) > > >
Re: Release Planning for 1.1.1 and others?
Hi Jungtaek, I think we're not too far off for most of the issues I'm aware of. I'd like to get some fixes around topic compaction ( https://github.com/apache/storm/pull/2221 and https://github.com/apache/storm/pull/2217) in for 1.1.1. They should be mergeable once the 24 hour period has passed. I think it would also be good to get the maxUncommittedOffsets limit enforcement ( https://github.com/apache/storm/pull/2156) looked at, since it shouldn't require API changes and is a bugfix. Following 2156 and related to the two other PRs, there's also https://issues.apache.org/jira/browse/STORM-2546 which I think we should consider fixing. It's waiting for PR 2156 to be stabilized, but is hopefully an easy fix. See https://issues.apache.org/jira/browse/STORM-2343?focusedCommentId=16044785=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16044785 for the discussion. For 1.2.0, I think we should get in the KafkaSpoutConfig API changes and deprecations (https://github.com/apache/storm/pull/2215) and a 1.x version of the manual partition assignment bugfix ( https://github.com/apache/storm/pull/2150). 2017-07-17 11:25 GMT+02:00 Jungtaek Lim: > Hi devs, > > We released Storm 1.1.0 at the late March, and we didn't have short plan > for next release. > (We discussed Storm 2.0.0, and I think we're getting closer, a bit slowly > but steady.) > > While we still have some issues and pull requests for storm-kafka-client > which I think should be included to 1.0.1, but maybe we can start planning > 1.1.1, having epic issue for release as we did for prior releases, and also > other versions as well (1.2.0 or 2.0.0). > > Unless I'm missing something, looks like there're no critical bugs except > storm-kafka-client for 1.1.1 candidate. So I think we could roll out 1.1.1 > fairly soon after sorting out current issue on storm-kafka-client. I'm not > familiar with storm-kafka-client module hence I'd like to rely on Hugo or > Stig or other committers/contributors to sort out, but may spend some time > to be familiar and participate if its progress is going to be slow. > > Looking forward to hear your opinions. > > Thanks, > Jungtaek Lim (HeartSaVioR) >
Release Planning for 1.1.1 and others?
Hi devs, We released Storm 1.1.0 at the late March, and we didn't have short plan for next release. (We discussed Storm 2.0.0, and I think we're getting closer, a bit slowly but steady.) While we still have some issues and pull requests for storm-kafka-client which I think should be included to 1.0.1, but maybe we can start planning 1.1.1, having epic issue for release as we did for prior releases, and also other versions as well (1.2.0 or 2.0.0). Unless I'm missing something, looks like there're no critical bugs except storm-kafka-client for 1.1.1 candidate. So I think we could roll out 1.1.1 fairly soon after sorting out current issue on storm-kafka-client. I'm not familiar with storm-kafka-client module hence I'd like to rely on Hugo or Stig or other committers/contributors to sort out, but may spend some time to be familiar and participate if its progress is going to be slow. Looking forward to hear your opinions. Thanks, Jungtaek Lim (HeartSaVioR)