Re: [DISCUSS] Major version change for Apex Library (Malhar)

I have not seen any active discussion on the topic since Monday and I don't see how a full consensus in the subject can be reached as no any other solution is proposed other than to wait with no clear time-frame when package names may be unified and follow Apache recommendation. Thank you,

Re: [DISCUSS] Major version change for Apex Library (Malhar)

On Fri, Sep 1, 2017 at 6:27 PM, Amol Kekre wrote: > This vote was not done per process. The discussion was still on going. A > decision that is more of code impact (consensus) is being called a > procedural decision (majority vote). Moreover end of vote day/time was also >

[DISCUSS] Major version change for Apex Library (Malhar)

On Fri, Sep 1, 2017 at 11:34 AM, Pramod Immaneni wrote: > > > > Regarding procedural vote, the decision to start development towards new > > major release is a longer term decision, not just code change. > > > > Longer term decision does not mean procedural change. You

Re: [DISCUSS] Major version change for Apex Library (Malhar)

This vote was not done per process. The discussion was still on going. A decision that is more of code impact (consensus) is being called a procedural decision (majority vote). Moreover end of vote day/time was also not called ahead of the vote to determine when the vote ends. These seem to be a

[DISCUSS] Major version change for Apex Library (Malhar)

The first step in allowing a real community to grow would be to wear the project hat, participate in discussions as individual, and consider how to enable changes vs. trying to block active community members that contribute on their own time from taking the project forward. Versioning and

Re: [RESULT] [VOTE] Major version change for Apex Library (Malhar)

I totally agree with Sandesh. Things are being pushed when there is clear disagreement. If Apex has to grow the community, it can't grow using divide and conquer method. On Fri, Sep 1, 2017 at 10:45 PM, Sandesh Hegde wrote: > Using all the technicalities and loop holes,

[jira] [Closed] (APEXCORE-782) Adding analysis to EventInfo

[ https://issues.apache.org/jira/browse/APEXCORE-782?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sandesh closed APEXCORE-782. Resolution: Invalid Can be done without changing the EventInfo. > Adding analysis to EventInfo >

[jira] [Reopened] (APEXCORE-782) Adding analysis to EventInfo

[ https://issues.apache.org/jira/browse/APEXCORE-782?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sandesh reopened APEXCORE-782: -- > Adding analysis to EventInfo > > > Key: APEXCORE-782 >

[jira] [Commented] (APEXCORE-782) Adding analysis to EventInfo

[ https://issues.apache.org/jira/browse/APEXCORE-782?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16151109#comment-16151109 ] ASF GitHub Bot commented on APEXCORE-782: - vinaydt closed pull request #577: APEXCORE-782 -

[jira] [Closed] (APEXCORE-782) Adding analysis to EventInfo

[ https://issues.apache.org/jira/browse/APEXCORE-782?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vinay Bangalore Srikanth closed APEXCORE-782. - Resolution: Feedback Received > Adding analysis to EventInfo >

[jira] [Commented] (APEXCORE-782) Adding analysis to EventInfo

[ https://issues.apache.org/jira/browse/APEXCORE-782?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16151106#comment-16151106 ] Vinay Bangalore Srikanth commented on APEXCORE-782: --- HashMap "data" on the EventInfo

Re: [RESULT] [VOTE] Major version change for Apex Library (Malhar)

My response inline On Fri, Sep 1, 2017 at 9:31 AM, Thomas Weise wrote: > Yes, you would need a separate discussion/vote on changes not being > reflected in master that you make to a branch (current procedure). > I don't think this was requested as a general policy and it

Re: [RESULT] [VOTE] Major version change for Apex Library (Malhar)

Using all the technicalities and loop holes, we can declare many votes invalid. What purpose does it solve? This thread is dividing the community, instead of recognizing the difference if we move forward with this, there is a chance that Apex will alienate many contributors. What's the end game

[jira] [Commented] (APEXCORE-781) Autometric values of an operator is showing wrongly in App master

[ https://issues.apache.org/jira/browse/APEXCORE-781?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16150706#comment-16150706 ] ASF GitHub Bot commented on APEXCORE-781: - chaithu14 opened a new pull request #578:

Re: [RESULT] [VOTE] Major version change for Apex Library (Malhar)

On 2017-09-01 10:36, Pramod Immaneni wrote: > Thomas, > > Wouldn't you need to call a separate procedural vote for whether changes > cannot be allowed into 3.x without requiring they be submitted to 4.x as > there was a disagreement there? Also, I am not sure that the

Re: [RESULT] [VOTE] Major version change for Apex Library (Malhar)

On 2017-09-01 08:54, Thomas Weise wrote: > There wasn't any more discussion on this, so here is the result: > > 1. Version 4.0 as major version change from 3.x > > > +1 (7) > > Thomas Weise (PMC) > Ananth G > Vlad Rozov (PMC) > Munagala

Re: [VOTE] Major version change for Apex Library (Malhar)

I think the backward in-compatibility is there in both options. I think we should give sufficient time frame for community members/ users for major changes. So, I'm -1 on both options. On Fri, Sep 1, 2017 at 5:43 PM, Sandeep Deshmukh wrote: > -1 from my side for

Re: [VOTE] Major version change for Apex Library (Malhar)

-1 for option 2 as well. I do not see any reason why we should do so. This will just confuse the users. On Fri, Sep 1, 2017 at 5:48 PM, Yogi Devendra wrote: > One thing which is not clear to me is: if someone has any contributions > planned for 3.x; will that

Re: [VOTE] Major version change for Apex Library (Malhar)

One thing which is not clear to me is: if someone has any contributions planned for 3.x; will that contribution need 2 different PRs? If yes, then can we avoid this by giving sufficient time for the community to prepare for this change? -1 for immediate release. -1 for immediate separation for

Re: [VOTE] Major version change for Apex Library (Malhar)

-1 from my side for "1. Version 4.0 as major version change from 3.x" Was out of station for festival season in India so delay in voting and replying. Reason: I don't see a compelling reason for a major change at this moment. As a user of Apex, I have developed a system using Apex but now I

Re: [RESULT] [VOTE] Major version change for Apex Library (Malhar)

I would suggest following: 1. Announce some end date for 3.x new features. (To give sufficient time for community members to plan their feature contributions.) 2. 3.x to 4.x migration should happen on this date. 3. Community members can submit 3.x PRs till this date. 4. New PRs after this date

Re: [VOTE] Major version change for Apex Library (Malhar)

Apologies for being late in discussions. I wanted to understand one thing. As Thomas mentioned some of our operators are not matured enought or lacks operability. Do we know if such operators need any backword incompatible changes? e.g. modification to api etc? Do we have plan to promote operators

Re: [VOTE] Major version change for Apex Library (Malhar)

Hi First of all my apologies for voting late. However, I will still do it since the mail says the vote would remain open for *at least* 72 hours :) I believe the objective is to do the right things rightly. Moving to a new version is something that is a part of any product lifecycle. While doing