Re: [DISCUSS] Storm 2.0 Roadmap

[Jungtaek Lim]

Yes I prefer option 1, but it might depend on the progress of metrics V2.
If it can be done within predictable near future I'm OK to pick option 2,
but if not, we may be better to focus releasing 2.0.0 and make it really
happen.

Whichever we go, I feel it's time to track remaining work on Storm 2.0.0. I
found some bugs on master branch so filed issues, and we've remaining port
work (UI and logviewer). We've some other improvements target for 2.0.0:
worker redesign, beam integration, and so on, and we don't track its
progress at all. I don't think we should wait for features which progress
is not transparent (in other words we don't know when it will be finished).

- Jungtaek Lim (HeartSaVioR)

2017년 6월 24일 (토) 오전 5:19, P. Taylor Goetz 님이 작성:

> Bobby/Jungtaek,
>
> Are you saying you want to forego the 1.2 “metrics_v2” release and include
> it only in 2.0? (I ask because that work is already based on 1.x-branch,
> and forward-porting it to master is relatively simple.) I’d kind of like
> that work go out soon.
>
> If we go with option 1, I would want to see a 2.0 release (even if it’s a
> “beta” or “preview) before putting the 1.x line into maintenance mode.
>
> -Taylor
>
> > On Jun 23, 2017, at 9:51 AM, Bobby Evans 
> wrote:
> >
> > I see 2 ways to address this.
> > 1) We put the 1.x line into maintenance mode like with 0.10.  We don't
> backport anything except bug fixes.2) We backport a lot of the backwards
> compatible changes from 2.x to 1.x.
> > My personal preference is 1.  It makes it clear the direction we want to
> go in.  The biggest issue is that we probably would want to do a 2.x
> release sooner rather then later.  Even if we don't get all of the features
> that people want, if we just get a release out we can add in new features
> if they are backwards compatible, or we can create a 3.x line that would
> have the breaking changes in it.
> >
> > - Bobby
> >
> >
> > On Thursday, June 22, 2017, 7:39:55 PM CDT, Jungtaek Lim <
> kabh...@gmail.com> wrote:
> >
> > I'd like to bump this again instead of initiating new discussion thread.
> >
> > I had having hard time to create and apply pull requests for both master
> > and 1.x-branch and that's really painful and sometimes blocker for me to
> do
> > merge step.
> > Two branches are heavily diverged more than between 0.10 and 1.0.0, even
> > IDE can't switch between the branch smoothly. We didn't even address
> > checkstyle issue yet, but after addressing, it could be "completely"
> > diverged. JDK version is another major issue, since the pull requests
> > targeted for master branch are not checked against JDK 7, and some of
> them
> > make some issues regarding JDK version while porting back.
> >
> > So personally I really would like to see the plan for 1.x version line
> > changed - skipping any minor releases including 1.2.0 - and have epic
> issue
> > for 2.0.0 and just go ahead. That was our proposed plan indeed. (even
> > proposed plan was having 2.0.0 directly after 1.0.0)
> >
> > Would like to hear everyone's opinions. If we have consensus to not
> having
> > any minor releases for 1.x version line, I will not port back non-bugfix
> > pull requests to 1.x-branch, and guide contributors to create pull
> requests
> > against master branch, not 1.x version line.
> >
> > Thanks,
> > Jungtaek Lim (HeartSaVioR)
> >
> > 2017년 6월 4일 (일) 오전 1:17, Alexandre Vermeerbergen <
> avermeerber...@gmail.com>님이
> > 작성:
> >
> >> +1 for Roshan's suggestion : in our Storm 1.x based supervision system,
> >> we're very interested anything that can provide better throughput.
> >>
> >> 2017-06-03 18:12 GMT+02:00 Roshan Naik :
> >>
> >>> For 2.0 beta … it would be good to incorporate some of the Worker
> >>> improvements (STORM-2284)  IMO. Changes to messaging subsystem can be
> >>> delivered sooner and my in-progress implementation suggests that it
> will
> >>> yield substantial latency improvements. The 2.0 beta phase would really
> >>> help kick the tires on the revised messaging system and the performance
> >>> improvements will also be a good incentive for trying out the 2.0 line.
> >>>
> >>> I notice multiple other bottlenecks that are holding back throughput a
> >>> lot, which can be addressed in a subsequent 2.x minor release.
> >>> -roshan
> >>>
> >>>
> >>> On 6/3/17, 7:20 AM, "Jungtaek Lim"  wrote:
> >>>
> >>> I also would love to see metrics V2 code sooner or later too. If we
> >>> can get
> >>> it before releasing 2.0.0 that will be great, and then maybe we
> could
> >>> just
> >>> move toward to 2.0.0, not adding any improvements to 1.x version
> >> line.
> >>> (And that's what I would want to.)
> >>>
> >>> If we would really want to have 1.2.0, I suggest that we make the
> >> 1.1.1
> >>> version correct right now rather than after releasing 1.1.1. We
> also
> >>> merged
> >>> non-bugfix things to 1.x-branch but that's not what users 

[GitHub] storm pull request #2176: STORM-2598 Add proxy server option for dependency ...

[HeartSaVioR]

GitHub user HeartSaVioR opened a pull request:

https://github.com/apache/storm/pull/2176

STORM-2598 Add proxy server option for dependency resolver

* add options to storm.py and dependency resolver: --proxyUrl, 
--proxyUsername, --proxyPassword
* address some checkstyle issue for storm-submit-tool

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/HeartSaVioR/storm STORM-2598

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/storm/pull/2176.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #2176


commit c2477520c18ee56401d2517b09e372b6d58df559
Author: Jungtaek Lim 
Date:   2017-06-24T04:48:32Z

STORM-2598 Add proxy server option for dependency resolver

* add options to storm.py and dependency resolver: --proxyUrl, 
--proxyUsername, --proxyPassword
* address some checkstyle issue for storm-submit-tool




---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] storm pull request #2175: (1.x) STORM-2598 Add proxy server option for depen...

[HeartSaVioR]

GitHub user HeartSaVioR opened a pull request:

https://github.com/apache/storm/pull/2175

(1.x) STORM-2598 Add proxy server option for dependency resolver

* add options to storm.py and dependency resolver: --proxyUrl, 
--proxyUsername, --proxyPassword
* address some checkstyle issue for storm-submit-tool

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/HeartSaVioR/storm STORM-2598-1.x

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/storm/pull/2175.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #2175


commit b737c41a658ce21c69e9343055d5130fa110bd96
Author: Jungtaek Lim 
Date:   2017-06-24T04:48:32Z

STORM-2598 Add proxy server option for dependency resolver

* add options to storm.py and dependency resolver: --proxyUrl, 
--proxyUsername, --proxyPassword
* address some checkstyle issue for storm-submit-tool




---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] storm pull request #2160: STORM-2555 handle impersonation properly for HBase...

[asfgit]

Github user asfgit closed the pull request at:

https://github.com/apache/storm/pull/2160


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] storm pull request #2171: (1.x) STORM-2555 handle impersonation properly for...

[asfgit]

Github user asfgit closed the pull request at:

https://github.com/apache/storm/pull/2171


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] storm pull request #2150: STORM-2541: Fix storm-kafka-client manual subscrip...

[hmcl]

Github user hmcl commented on a diff in the pull request:

https://github.com/apache/storm/pull/2150#discussion_r123868570
  
--- Diff: 
external/storm-kafka-client/src/main/java/org/apache/storm/kafka/spout/ManualPartitionSubscription.java
 ---
@@ -58,21 +51,21 @@ public 
ManualPartitionNamedSubscription(ManualPartitioner parter, String ... top
 
 @Override
 public void refreshAssignment() {
-List allPartitions = new ArrayList<>();
-for (String topic : topics) {
-for (PartitionInfo partitionInfo: 
consumer.partitionsFor(topic)) {
-allPartitions.add(new 
TopicPartition(partitionInfo.topic(), partitionInfo.partition()));
-}
-}
+List allPartitions = 
partitionFilter.getFilteredTopicPartitions(consumer);
 Collections.sort(allPartitions, TopicPartitionComparator.INSTANCE);
 Set newAssignment = new 
HashSet<>(partitioner.partition(allPartitions, context));
 if (!newAssignment.equals(currentAssignment)) {
+consumer.assign(newAssignment);
 if (currentAssignment != null) {
 listener.onPartitionsRevoked(currentAssignment);
-listener.onPartitionsAssigned(newAssignment);
 }
+listener.onPartitionsAssigned(newAssignment);
 currentAssignment = newAssignment;
-consumer.assign(currentAssignment);
--- End diff --

@srdo lines 62 and 63 should be switched. We want to call the listener only 
once all is set.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] storm pull request #2150: STORM-2541: Fix storm-kafka-client manual subscrip...

[hmcl]

Github user hmcl commented on a diff in the pull request:

https://github.com/apache/storm/pull/2150#discussion_r123868726
  
--- Diff: 
external/storm-kafka-client/src/main/java/org/apache/storm/kafka/spout/TopicFilter.java
 ---
@@ -0,0 +1,38 @@
+/*
+ * Copyright 2017 The Apache Software Foundation.
+ *
+ * Licensed under the Apache License, Version 2.0 (the "License");
+ * you may not use this file except in compliance with the License.
+ * You may obtain a copy of the License at
+ *
+ *  http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+
+package org.apache.storm.kafka.spout;
+
+import java.util.List;
+import org.apache.kafka.clients.consumer.KafkaConsumer;
+import org.apache.kafka.common.TopicPartition;
+
+public interface TopicFilter {
--- End diff --

must implement Serializable. Otherwise code didn't work for me. The trident 
[changes](https://github.com/hmcl/storm-apache/blob/35f2c0c71a28a065e64f523b861acd883b2f2101/external/storm-kafka-client/src/main/java/org/apache/storm/kafka/spout/TopicFilter.java#L24)
 are already do this.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] storm pull request #2150: STORM-2541: Fix storm-kafka-client manual subscrip...

[hmcl]

Github user hmcl commented on a diff in the pull request:

https://github.com/apache/storm/pull/2150#discussion_r123868742
  
--- Diff: 
external/storm-kafka-client/src/main/java/org/apache/storm/kafka/spout/PatternTopicFilter.java
 ---
@@ -0,0 +1,59 @@
+/*
+ * Copyright 2017 The Apache Software Foundation.
+ *
+ * Licensed under the Apache License, Version 2.0 (the "License");
+ * you may not use this file except in compliance with the License.
+ * You may obtain a copy of the License at
+ *
+ *  http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+
+package org.apache.storm.kafka.spout;
+
+import java.util.ArrayList;
+import java.util.List;
+import java.util.Map;
+import java.util.regex.Pattern;
+import org.apache.kafka.clients.consumer.KafkaConsumer;
+import org.apache.kafka.common.PartitionInfo;
+import org.apache.kafka.common.TopicPartition;
+
+/**
+ * Filter that returns all partitions for topics matching the given {@link 
Pattern}.
+ */
+public class PatternTopicFilter implements TopicFilter {
+
+private final Pattern pattern;
+
+/**
+ * Creates filter based on a Pattern. Only topic names matching the 
Pattern are passed by the filter.
+ * @param pattern The Pattern to use.
+ */
+public PatternTopicFilter(Pattern pattern) {
+this.pattern = pattern;
+}
+
+@Override
+public List 
getFilteredTopicPartitions(KafkaConsumer consumer) {
+List allPartitions = new ArrayList<>();
+for (Map.Entry entry: 
consumer.listTopics().entrySet()) {
+if (pattern.matcher(entry.getKey()).matches()) {
+for (PartitionInfo partitionInfo: entry.getValue()) {
+allPartitions.add(new 
TopicPartition(partitionInfo.topic(), partitionInfo.partition()));
+}
+}
+}
+return allPartitions;
+}
+
+@Override
+public String getTopicsString() {
+return pattern.pattern();
--- End diff --

This implementation should be for a method called getTopicsPattern. Please 
make a diff with my [slight 
modification](https://github.com/hmcl/storm-apache/blob/35f2c0c71a28a065e64f523b861acd883b2f2101/external/storm-kafka-client/src/main/java/org/apache/storm/kafka/spout/PatternTopicFilter.java)
 of your changes. I suggest that you incorporate that diff in this patch.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] storm pull request #2174: STORM-2554: Trident Kafka Spout Refactoring to Inc...

[hmcl]

GitHub user hmcl opened a pull request:

https://github.com/apache/storm/pull/2174

STORM-2554: Trident Kafka Spout Refactoring to Include Manual Partition 
Assignment

  - Support manual partition assignment with changes in STORM-2541
  - Improve rebalance pause/resume logic

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/hmcl/storm-apache 
Apache_master_STORM-2554_KTSMPA

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/storm/pull/2174.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #2174


commit 35f2c0c71a28a065e64f523b861acd883b2f2101
Author: Hugo Louro 
Date:   2017-05-27T17:02:21Z

STORM-2554: Trident Kafka Spout Refactoring to Include Manual Partition 
Assignment
  - Support manual partition assignment with changes in STORM-2541
  - Improve rebalance pause/resume logic




---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

Re: [DISCUSS] Storm 2.0 Roadmap

[P. Taylor Goetz]

Bobby/Jungtaek,

Are you saying you want to forego the 1.2 “metrics_v2” release and include it 
only in 2.0? (I ask because that work is already based on 1.x-branch, and 
forward-porting it to master is relatively simple.) I’d kind of like that work 
go out soon. 

If we go with option 1, I would want to see a 2.0 release (even if it’s a 
“beta” or “preview) before putting the 1.x line into maintenance mode. 

-Taylor

> On Jun 23, 2017, at 9:51 AM, Bobby Evans  wrote:
> 
> I see 2 ways to address this.
> 1) We put the 1.x line into maintenance mode like with 0.10.  We don't 
> backport anything except bug fixes.2) We backport a lot of the backwards 
> compatible changes from 2.x to 1.x.
> My personal preference is 1.  It makes it clear the direction we want to go 
> in.  The biggest issue is that we probably would want to do a 2.x release 
> sooner rather then later.  Even if we don't get all of the features that 
> people want, if we just get a release out we can add in new features if they 
> are backwards compatible, or we can create a 3.x line that would have the 
> breaking changes in it.
> 
> - Bobby
> 
> 
> On Thursday, June 22, 2017, 7:39:55 PM CDT, Jungtaek Lim  
> wrote:
> 
> I'd like to bump this again instead of initiating new discussion thread.
> 
> I had having hard time to create and apply pull requests for both master
> and 1.x-branch and that's really painful and sometimes blocker for me to do
> merge step.
> Two branches are heavily diverged more than between 0.10 and 1.0.0, even
> IDE can't switch between the branch smoothly. We didn't even address
> checkstyle issue yet, but after addressing, it could be "completely"
> diverged. JDK version is another major issue, since the pull requests
> targeted for master branch are not checked against JDK 7, and some of them
> make some issues regarding JDK version while porting back.
> 
> So personally I really would like to see the plan for 1.x version line
> changed - skipping any minor releases including 1.2.0 - and have epic issue
> for 2.0.0 and just go ahead. That was our proposed plan indeed. (even
> proposed plan was having 2.0.0 directly after 1.0.0)
> 
> Would like to hear everyone's opinions. If we have consensus to not having
> any minor releases for 1.x version line, I will not port back non-bugfix
> pull requests to 1.x-branch, and guide contributors to create pull requests
> against master branch, not 1.x version line.
> 
> Thanks,
> Jungtaek Lim (HeartSaVioR)
> 
> 2017년 6월 4일 (일) 오전 1:17, Alexandre Vermeerbergen 님이
> 작성:
> 
>> +1 for Roshan's suggestion : in our Storm 1.x based supervision system,
>> we're very interested anything that can provide better throughput.
>> 
>> 2017-06-03 18:12 GMT+02:00 Roshan Naik :
>> 
>>> For 2.0 beta … it would be good to incorporate some of the Worker
>>> improvements (STORM-2284)  IMO. Changes to messaging subsystem can be
>>> delivered sooner and my in-progress implementation suggests that it will
>>> yield substantial latency improvements. The 2.0 beta phase would really
>>> help kick the tires on the revised messaging system and the performance
>>> improvements will also be a good incentive for trying out the 2.0 line.
>>> 
>>> I notice multiple other bottlenecks that are holding back throughput a
>>> lot, which can be addressed in a subsequent 2.x minor release.
>>> -roshan
>>> 
>>> 
>>> On 6/3/17, 7:20 AM, "Jungtaek Lim"  wrote:
>>> 
>>> I also would love to see metrics V2 code sooner or later too. If we
>>> can get
>>> it before releasing 2.0.0 that will be great, and then maybe we could
>>> just
>>> move toward to 2.0.0, not adding any improvements to 1.x version
>> line.
>>> (And that's what I would want to.)
>>> 
>>> If we would really want to have 1.2.0, I suggest that we make the
>> 1.1.1
>>> version correct right now rather than after releasing 1.1.1. We also
>>> merged
>>> non-bugfix things to 1.x-branch but that's not what users expect. I
>>> agree
>>> that work may be painful, but anyway need to do it.
>>> 
>>> - Jungtaek Lim (HeartSaVioR)
>>> 
>>> 2017년 6월 3일 (토) 오전 3:49, Bobby Evans 님이
>>> 작성:
>>> 
>>> > I would love to see the metrics V2 code come out sooner rather than
>>> > later.  +1.
>>> > My biggest blocker for a 1.x release is
>>> > https://github.com/apache/storm/pull/2142  Even though the pull
>>> request
>>> > says it is minor it showed that we messed up pushing back some
>>> changes for
>>> > pacemaker to open source (the code does not run at all which for me
>>> is a
>>> > blocker) and I really want to get that fully fixed/tested before
>>> another
>>> > release.
>>> > As for 2.x I think we are very close to being able to so a 2.x
>> alpha
>>> > release.  I would like to see metrics V2 merged in simply because
>> it
>>> is a
>>> > big 

[GitHub] storm pull request #2173: STORM-2597: Don't parse passed in class paths

[revans2]

GitHub user revans2 opened a pull request:

https://github.com/apache/storm/pull/2173

STORM-2597: Don't parse passed in class paths



You can merge this pull request into a Git repository by running:

$ git pull https://github.com/revans2/incubator-storm STORM-2597

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/storm/pull/2173.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #2173


commit ddf11b156e8386e425da533ab96d584254ab3858
Author: Robert (Bobby) Evans 
Date:   2017-06-23T19:23:52Z

STORM-2597: Don't parse passed in class paths




---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] storm issue #2149: STORM-2503: Fix lgtm.com alerts on equality and compariso...

[revans2]

Github user revans2 commented on the issue:

https://github.com/apache/storm/pull/2149
  
Yes I just put up a pull request that makes the ordering of the executors 
consistent.  I don't know what changed between JDK7 and JDK 8 that would cause 
the order of the executors to be different but it was.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] storm issue #2149: STORM-2503: Fix lgtm.com alerts on equality and compariso...

[revans2]

Github user revans2 commented on the issue:

https://github.com/apache/storm/pull/2149
  
OK It looks like it is a difference between java7 and java8, and the 
default ordering of something.  I'll try to see if I can make it less ambiguous.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] storm issue #2149: STORM-2503: Fix lgtm.com alerts on equality and compariso...

[revans2]

Github user revans2 commented on the issue:

https://github.com/apache/storm/pull/2149
  
@HeartSaVioR both of those are valid schedulings and I am not totally sure 
why one would be picked in one release vs another.  I'll try to reproduce the 
issue and see what I can come up with.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

Re: [DISCUSS] Storm 2.0 Roadmap

[Bobby Evans]

I see 2 ways to address this.
1) We put the 1.x line into maintenance mode like with 0.10.  We don't backport 
anything except bug fixes.2) We backport a lot of the backwards compatible 
changes from 2.x to 1.x.
My personal preference is 1.  It makes it clear the direction we want to go in. 
 The biggest issue is that we probably would want to do a 2.x release sooner 
rather then later.  Even if we don't get all of the features that people want, 
if we just get a release out we can add in new features if they are backwards 
compatible, or we can create a 3.x line that would have the breaking changes in 
it.

- Bobby


On Thursday, June 22, 2017, 7:39:55 PM CDT, Jungtaek Lim  
wrote:

I'd like to bump this again instead of initiating new discussion thread.

I had having hard time to create and apply pull requests for both master
and 1.x-branch and that's really painful and sometimes blocker for me to do
merge step.
Two branches are heavily diverged more than between 0.10 and 1.0.0, even
IDE can't switch between the branch smoothly. We didn't even address
checkstyle issue yet, but after addressing, it could be "completely"
diverged. JDK version is another major issue, since the pull requests
targeted for master branch are not checked against JDK 7, and some of them
make some issues regarding JDK version while porting back.

So personally I really would like to see the plan for 1.x version line
changed - skipping any minor releases including 1.2.0 - and have epic issue
for 2.0.0 and just go ahead. That was our proposed plan indeed. (even
proposed plan was having 2.0.0 directly after 1.0.0)

Would like to hear everyone's opinions. If we have consensus to not having
any minor releases for 1.x version line, I will not port back non-bugfix
pull requests to 1.x-branch, and guide contributors to create pull requests
against master branch, not 1.x version line.

Thanks,
Jungtaek Lim (HeartSaVioR)

2017년 6월 4일 (일) 오전 1:17, Alexandre Vermeerbergen 님이
작성:

> +1 for Roshan's suggestion : in our Storm 1.x based supervision system,
> we're very interested anything that can provide better throughput.
>
> 2017-06-03 18:12 GMT+02:00 Roshan Naik :
>
> > For 2.0 beta … it would be good to incorporate some of the Worker
> > improvements (STORM-2284)  IMO. Changes to messaging subsystem can be
> > delivered sooner and my in-progress implementation suggests that it will
> > yield substantial latency improvements. The 2.0 beta phase would really
> > help kick the tires on the revised messaging system and the performance
> > improvements will also be a good incentive for trying out the 2.0 line.
> >
> > I notice multiple other bottlenecks that are holding back throughput a
> > lot, which can be addressed in a subsequent 2.x minor release.
> > -roshan
> >
> >
> > On 6/3/17, 7:20 AM, "Jungtaek Lim"  wrote:
> >
> >    I also would love to see metrics V2 code sooner or later too. If we
> > can get
> >    it before releasing 2.0.0 that will be great, and then maybe we could
> > just
> >    move toward to 2.0.0, not adding any improvements to 1.x version
> line.
> >    (And that's what I would want to.)
> >
> >    If we would really want to have 1.2.0, I suggest that we make the
> 1.1.1
> >    version correct right now rather than after releasing 1.1.1. We also
> > merged
> >    non-bugfix things to 1.x-branch but that's not what users expect. I
> > agree
> >    that work may be painful, but anyway need to do it.
> >
> >    - Jungtaek Lim (HeartSaVioR)
> >
> >    2017년 6월 3일 (토) 오전 3:49, Bobby Evans 님이
> > 작성:
> >
> >    > I would love to see the metrics V2 code come out sooner rather than
> >    > later.  +1.
> >    > My biggest blocker for a 1.x release is
> >    > https://github.com/apache/storm/pull/2142  Even though the pull
> > request
> >    > says it is minor it showed that we messed up pushing back some
> > changes for
> >    > pacemaker to open source (the code does not run at all which for me
> > is a
> >    > blocker) and I really want to get that fully fixed/tested before
> > another
> >    > release.
> >    > As for 2.x I think we are very close to being able to so a 2.x
> alpha
> >    > release.  I would like to see metrics V2 merged in simply because
> it
> > is a
> >    > big change for user facing APIs.  But after that I would love to
> see
> > us
> >    > starting to push forward on getting that out.
> >    >
> >    >
> >    > - Bobby
> >    >
> >    >
> >    > On Friday, June 2, 2017, 1:39:46 PM CDT, P. Taylor Goetz <
> >    > ptgo...@gmail.com> wrote:
> >    >
> >    > I’d like to bump this thread and start a discussion around our next
> >    > release. Here are my thoughts.
> >    >
> >    > There are a number of important fixes in 1.x-branch so I’d like to
> >    > consider releasing 1.1.1 soon. I’d appreciate input on any open
> > issues that
> >    > should be resolved for that release.
> >    >
> 

[GitHub] storm issue #2160: STORM-2555 handle impersonation properly for HBase delega...

[arunmahadevan]

Github user arunmahadevan commented on the issue:

https://github.com/apache/storm/pull/2160
  
+1 LGTM


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] storm issue #2160: STORM-2555 handle impersonation properly for HBase delega...

[HeartSaVioR]

Github user HeartSaVioR commented on the issue:

https://github.com/apache/storm/pull/2160
  
@arunmahadevan 
I think the changeset is same as #2171 except fixing some styles. Could you 
review this as well?


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---