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

2017-08-23 Thread Sergey Golovko
-1 for the option 2 I don't think it makes sense to rush to rename the package name. There are Apache Java projects that use the original package names after migration to Apache Software Foundation. For instance, Apache Felix (org.osgi) Apache

[DISCUSS] changing project name to apex-library

2017-08-23 Thread Vlad Rozov
Please see my comments in-line. Thank you, Vlad On 8/23/17 09:11, Pramod Immaneni wrote: That is not accurate, I have mentioned and probably others as well that changing the name of the project would be disruptive to users. Users are used to using the malhar project and its artifacts a

Re: -1 or veto voting

2017-08-23 Thread Pramod Immaneni
That is not accurate, I have mentioned and probably others as well that changing the name of the project would be disruptive to users. Users are used to using the malhar project and its artifacts a certain way and this would cause them immediate confusion followed by consternation and then changes

Re: -1 or veto voting

2017-08-23 Thread Thomas Weise
There was plenty of discussion over several months about this and the 3.x vs. 4.0 trade off is part of it. If there is no agreement to make a binary compatible change in 3.x then the only way forward is 4.0, and that was expressed by those that participated with constructive suggestions. You have

Re: -1 or veto voting

2017-08-23 Thread Vlad Rozov
All -1 are technically void at this point as justification given are why project may continue without modifications and not why the modification must not be done. Whether we proceed with the vote or with the discussion, arguments should be what are pros and cons of a code change, not that the

Re: -1 or veto voting

2017-08-23 Thread Amol Kekre
Thomas, My worry is that consequences of main-branch being 4.x have not been discussed in detail. How about we take that up on discussion thread. I can volunteer to put 4.x to vote post that discussion. Thks, Amol E:a...@datatorrent.com | M: 510-449-2606 | Twitter: @*amolhkekre*

Re: -1 or veto voting

2017-08-23 Thread Thomas Weise
The earlier discussion had concerns about making changes in 3.x and the expressed preference was major version change. Accordingly the vote is for major version change. On Wed, Aug 23, 2017 at 6:56 AM, Amol Kekre wrote: > The earlier discussion had concerns about this

Re: -1 or veto voting

2017-08-23 Thread Amol Kekre
The earlier discussion had concerns about this vote and the need to brand to 4.x right now. IMO they were not sufficiently addressed. Thks Amol E:a...@datatorrent.com | M: 510-449-2606 | Twitter: @*amolhkekre* www.datatorrent.com On Wed, Aug 23, 2017 at 6:54 AM, Thomas Weise

Re: -1 or veto voting

2017-08-23 Thread Thomas Weise
The discussion already took place [1]. There are two options under vote out of that discussion and for the first option there is a single -1. Use of -1 during voting (and veto on PR) when not showing up during the preceding discussion is problematic. Thomas [1]

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

2017-08-23 Thread Thomas Weise
So far everyone else has voted +1 on option 1. Your -1 is not a veto (unlike your previous -1 on a pull request), but your response also states "I am for option 1" and that you want to have the branch release-3 included. So why don't you include that into your vote for option 1 as a condition,

Re: -1 or veto voting

2017-08-23 Thread Justin Mclean
Hi, Votes are only valid on code modifications with a reason. [1] However it looks to me that there’s not consensus and which way forward is best I would suggest cancelling the vote and having a discussion of the benefit or not of making the change. Thanks, Justin 1.

-1 or veto voting

2017-08-23 Thread Vlad Rozov
According to [1] unless the veto is followed by a technical justification showing why the change is bad it is considered to be an invalid or void veto. Technically project may continue with or without the modification and nothing bad will happen. In addition, maven supports project relocation