Re: -1 or veto voting

[Thomas Weise]

Justification is to not mingle small changes with refactoring and not
perform refactoring of this kind without adequate discussion. Both was
already conveyed on current PR and previous PR.

You did the right thing declaring your intent to merge without just pulling
the trigger, but you also need to allow for reasonable time for folks to
respond to email.


On Thu, Aug 24, 2017 at 12:02 PM, Sandesh Hegde 
wrote:

> Today, I saw the below -1 by Thomas,
> https://github.com/apache/apex-malhar/pull/666 without the technical
> justification.
>
> Saumya, PR Author, has created a mail thread to discuss the justification,
> but there was no comment in the mail thread.
>
> So should we consider this as invalid -1?
>
> On Thu, Aug 24, 2017 at 10:08 AM Vlad Rozov  wrote:
>
> > For -1 to be valid there *must* be *technical* justification(s) not to
> > proceed with the code change. Without such justification -1 is
> > considered to be void/invalid [1].
> >
> > I don't see any possible *technical* justification not to proceed with
> > the package rename as it was done in the past by a large number of
> > Apache (and not only Apache) projects  and nothing bad happened (no
> > performance degradation, no introduction of security vulnerability) and
> > projects remained usable by their users. With the current IDEs, it is a
> > question of 5 minutes to complete necessary modifications.
> >
> > Both Apache Felix and Apache Groovy (as well as Apache Apex) are split
> > package projects. There is mix and match of org.apache.* and other
> > package names (org.osgi, groovy, com.datatorrent). IMO, this is a bad
> > practice and I don't think that Apex community should use those projects
> > as a best practice examples. Majority of Apache projects consistently
> > use org.apache package and IMO that simplifies user and community
> > experience.
> >
> > Majority of malhar library classes are excluded from semantic versioning
> > check and are not subject of backward compatibility/stable API
> > guarantee. Due to that there never be a good reason to change major
> > version as backward incompatible changes are introduced silently and
> > without proper semantic versioning.
> >
> > Thank you,
> >
> > Vlad
> >
> > [1] https://www.apache.org/foundation/voting.html
> >
> > On 8/23/17 15:17, Sergey Golovko wrote:
> > > -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 Groovy 
> (groovy)
> > >
> > > Personally I don't like the idea to rename package names for any
> existing
> > > tools and applications. It can just be a big confusion for users
> without
> > > any real benefits.
> > >
> > > -1 for the option 1
> > >
> > > I see only one valid reason to change the major version now. It is the
> > full
> > > refactoring of the code without supporting of any backward
> compatibility.
> > > If we are going to make the package refactoring we need to change the
> > major
> > > version. If we are not going to do it now, it does not make sense to
> > > change the major version. I don't think it makes sense to vote for the
> > two
> > > options separately.
> > >
> > > Thanks,
> > > Sergey
> > >
> > >
> > > On Wed, Aug 23, 2017 at 6:39 AM, Thomas Weise  wrote:
> > >
> > >> 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, since that's what is going to happen anyways.
> > >>
> > >> Thomas
> > >>
> > >>
> > >> On Tue, Aug 22, 2017 at 6:17 PM, Amol Kekre 
> > wrote:
> > >>
> > >>> On just voting part, I remain -1 on both options
> > >>>
> > >>> Thks
> > >>> Amol
> > >>>
> > >>>
> > >>>
> > >> On Tue, Aug 22, 2017 at 10:03 AM, Amol Kekre 
> > wrote:
> > >>
> > >>> I am -1 on option 2. There is no need to do so, as going back on
> > versions
> > >>> at this stage has consequences to Apex users.
> > >>>
> > >>> I am for option 1, but I want to propose explicit change to the text.
> > >> Based
> > >>> on verbatim text, I am voting -1 on option 1. I believe in the
> original
> > >>> discussion thread there was talk about continuing release-3 that
> should
> > >> be
> > >>> explicit in the vote.
> > >>>
> > >>>
> >
> >
> > Thank you,
> >
> > Vlad
> >
>

Re: -1 or veto voting

[Sandesh Hegde]

Today, I saw the below -1 by Thomas,
https://github.com/apache/apex-malhar/pull/666 without the technical
justification.

Saumya, PR Author, has created a mail thread to discuss the justification,
but there was no comment in the mail thread.

So should we consider this as invalid -1?

On Thu, Aug 24, 2017 at 10:08 AM Vlad Rozov  wrote:

> For -1 to be valid there *must* be *technical* justification(s) not to
> proceed with the code change. Without such justification -1 is
> considered to be void/invalid [1].
>
> I don't see any possible *technical* justification not to proceed with
> the package rename as it was done in the past by a large number of
> Apache (and not only Apache) projects  and nothing bad happened (no
> performance degradation, no introduction of security vulnerability) and
> projects remained usable by their users. With the current IDEs, it is a
> question of 5 minutes to complete necessary modifications.
>
> Both Apache Felix and Apache Groovy (as well as Apache Apex) are split
> package projects. There is mix and match of org.apache.* and other
> package names (org.osgi, groovy, com.datatorrent). IMO, this is a bad
> practice and I don't think that Apex community should use those projects
> as a best practice examples. Majority of Apache projects consistently
> use org.apache package and IMO that simplifies user and community
> experience.
>
> Majority of malhar library classes are excluded from semantic versioning
> check and are not subject of backward compatibility/stable API
> guarantee. Due to that there never be a good reason to change major
> version as backward incompatible changes are introduced silently and
> without proper semantic versioning.
>
> Thank you,
>
> Vlad
>
> [1] https://www.apache.org/foundation/voting.html
>
> On 8/23/17 15:17, Sergey Golovko wrote:
> > -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 Groovy  (groovy)
> >
> > Personally I don't like the idea to rename package names for any existing
> > tools and applications. It can just be a big confusion for users without
> > any real benefits.
> >
> > -1 for the option 1
> >
> > I see only one valid reason to change the major version now. It is the
> full
> > refactoring of the code without supporting of any backward compatibility.
> > If we are going to make the package refactoring we need to change the
> major
> > version. If we are not going to do it now, it does not make sense to
> > change the major version. I don't think it makes sense to vote for the
> two
> > options separately.
> >
> > Thanks,
> > Sergey
> >
> >
> > On Wed, Aug 23, 2017 at 6:39 AM, Thomas Weise  wrote:
> >
> >> 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, since that's what is going to happen anyways.
> >>
> >> Thomas
> >>
> >>
> >> On Tue, Aug 22, 2017 at 6:17 PM, Amol Kekre 
> wrote:
> >>
> >>> On just voting part, I remain -1 on both options
> >>>
> >>> Thks
> >>> Amol
> >>>
> >>>
> >>>
> >> On Tue, Aug 22, 2017 at 10:03 AM, Amol Kekre 
> wrote:
> >>
> >>> I am -1 on option 2. There is no need to do so, as going back on
> versions
> >>> at this stage has consequences to Apex users.
> >>>
> >>> I am for option 1, but I want to propose explicit change to the text.
> >> Based
> >>> on verbatim text, I am voting -1 on option 1. I believe in the original
> >>> discussion thread there was talk about continuing release-3 that should
> >> be
> >>> explicit in the vote.
> >>>
> >>>
>
>
> Thank you,
>
> Vlad
>

Re: -1 or veto voting

[Vlad Rozov]

For -1 to be valid there *must* be *technical* justification(s) not to 
proceed with the code change. Without such justification -1 is 
considered to be void/invalid [1].


I don't see any possible *technical* justification not to proceed with 
the package rename as it was done in the past by a large number of 
Apache (and not only Apache) projects  and nothing bad happened (no 
performance degradation, no introduction of security vulnerability) and 
projects remained usable by their users. With the current IDEs, it is a 
question of 5 minutes to complete necessary modifications.


Both Apache Felix and Apache Groovy (as well as Apache Apex) are split 
package projects. There is mix and match of org.apache.* and other 
package names (org.osgi, groovy, com.datatorrent). IMO, this is a bad 
practice and I don't think that Apex community should use those projects 
as a best practice examples. Majority of Apache projects consistently 
use org.apache package and IMO that simplifies user and community 
experience.


Majority of malhar library classes are excluded from semantic versioning 
check and are not subject of backward compatibility/stable API 
guarantee. Due to that there never be a good reason to change major 
version as backward incompatible changes are introduced silently and 
without proper semantic versioning.


Thank you,

Vlad

[1] https://www.apache.org/foundation/voting.html

On 8/23/17 15:17, Sergey Golovko wrote:

-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 Groovy  (groovy)

Personally I don't like the idea to rename package names for any existing
tools and applications. It can just be a big confusion for users without
any real benefits.

-1 for the option 1

I see only one valid reason to change the major version now. It is the full
refactoring of the code without supporting of any backward compatibility.
If we are going to make the package refactoring we need to change the major
version. If we are not going to do it now, it does not make sense to
change the major version. I don't think it makes sense to vote for the two
options separately.

Thanks,
Sergey


On Wed, Aug 23, 2017 at 6:39 AM, Thomas Weise  wrote:


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, since that's what is going to happen anyways.

Thomas


On Tue, Aug 22, 2017 at 6:17 PM, Amol Kekre  wrote:


On just voting part, I remain -1 on both options

Thks
Amol




On Tue, Aug 22, 2017 at 10:03 AM, Amol Kekre  wrote:


I am -1 on option 2. There is no need to do so, as going back on versions
at this stage has consequences to Apex users.

I am for option 1, but I want to propose explicit change to the text.

Based

on verbatim text, I am voting -1 on option 1. I believe in the original
discussion thread there was talk about continuing release-3 that should

be

explicit in the vote.





Thank you,

Vlad

Re: -1 or veto voting

[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 that could extend beyond their application such as documentation
etc.

Second the project has been around for quite some time and has reached a
version 3.x, the second part of the proposed change is to reset it back to
1.0-SNAPSHOT. I don't think that is accurate for the project and the
maturity it would portray to the users. Not to get subjective but there are
operators in malhar that are best of the breed when it comes to streaming
functionality they achieve.

Third think about all the changes it would need, code, project
infrastructure such as github repo and jira project, documentation, website
etc and the time all the developers have to spend to adapt to this.
Wouldn't we want to spend this time doing something more productive.

I would think changing a project name and resetting the version is a big
deal and should be done if there something big to gain for the project by
doing this. What is the big gain we achieve to justify all this
consternation? If we want to increase adoption, one of the things we need
to do is to provide users with a platform that behaves in an expected and
stable manner.

Thanks


On Wed, Aug 23, 2017 at 8:09 AM Vlad Rozov  wrote:

> 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 project may continue without them. The same should apply
> not only to the current set of changes, but to all future discussions.
>
> Thank you,
>
> Vlad
>
> On 8/23/17 06:54, Thomas Weise wrote:
> > 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] https://lists.apache.org/thread.html/bd1db8a2d01e23b0c0ab98a785f6ee
> > 9492a1ac9e52d422568a46e5f3@%3Cdev.apex.apache.org%3E
> >
> > On Wed, Aug 23, 2017 at 1:58 AM, Justin Mclean  >
> > wrote:
> >
> >> 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. https://www.apache.org/foundation/voting.html
>
>
> Thank you,
>
> Vlad
>

Re: -1 or veto voting

[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 voted -1 on backward compatible change in 3.x , now you vote -1 to
go to 4.x while saying "I am for option 1", which is going to 4.x. All of
that with an apparently insufficient understanding of development process
and branching, stability/maturity of the code base and how backward
compatibility in Malhar has (or has not) worked over the past 2 years.

If you need clarification for yourself then IMO you should ask questions,
and not vote -1 all over the board.

Thomas


On Wed, Aug 23, 2017 at 7:55 AM, Amol Kekre  wrote:

> 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*
>
> www.datatorrent.com
>
>
> On Wed, Aug 23, 2017 at 7:03 AM, Thomas Weise  wrote:
>
> > 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 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  wrote:
> > >
> > > > 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] https://lists.apache.org/thread.html/
> > bd1db8a2d01e23b0c0ab98a785f6ee
> > > > 9492a1ac9e52d422568a46e5f3@%3Cdev.apex.apache.org%3E
> > > >
> > > > On Wed, Aug 23, 2017 at 1:58 AM, Justin Mclean <
> > jus...@classsoftware.com
> > > >
> > > > wrote:
> > > >
> > > > > 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. https://www.apache.org/foundation/voting.html
> > > >
> > >
> >
>

Re: -1 or veto voting

[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 project may continue without them. The same should apply 
not only to the current set of changes, but to all future discussions.


Thank you,

Vlad

On 8/23/17 06:54, Thomas Weise wrote:

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] https://lists.apache.org/thread.html/bd1db8a2d01e23b0c0ab98a785f6ee
9492a1ac9e52d422568a46e5f3@%3Cdev.apex.apache.org%3E

On Wed, Aug 23, 2017 at 1:58 AM, Justin Mclean 
wrote:


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. https://www.apache.org/foundation/voting.html



Thank you,

Vlad

Re: -1 or veto voting

[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*

www.datatorrent.com


On Wed, Aug 23, 2017 at 7:03 AM, Thomas Weise  wrote:

> 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 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  wrote:
> >
> > > 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] https://lists.apache.org/thread.html/
> bd1db8a2d01e23b0c0ab98a785f6ee
> > > 9492a1ac9e52d422568a46e5f3@%3Cdev.apex.apache.org%3E
> > >
> > > On Wed, Aug 23, 2017 at 1:58 AM, Justin Mclean <
> jus...@classsoftware.com
> > >
> > > wrote:
> > >
> > > > 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. https://www.apache.org/foundation/voting.html
> > >
> >
>

Re: -1 or veto voting

[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 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  wrote:
>
> > 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] https://lists.apache.org/thread.html/bd1db8a2d01e23b0c0ab98a785f6ee
> > 9492a1ac9e52d422568a46e5f3@%3Cdev.apex.apache.org%3E
> >
> > On Wed, Aug 23, 2017 at 1:58 AM, Justin Mclean  >
> > wrote:
> >
> > > 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. https://www.apache.org/foundation/voting.html
> >
>

Re: -1 or veto voting

[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  wrote:

> 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] https://lists.apache.org/thread.html/bd1db8a2d01e23b0c0ab98a785f6ee
> 9492a1ac9e52d422568a46e5f3@%3Cdev.apex.apache.org%3E
>
> On Wed, Aug 23, 2017 at 1:58 AM, Justin Mclean 
> wrote:
>
> > 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. https://www.apache.org/foundation/voting.html
>

Re: -1 or veto voting

[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] https://lists.apache.org/thread.html/bd1db8a2d01e23b0c0ab98a785f6ee
9492a1ac9e52d422568a46e5f3@%3Cdev.apex.apache.org%3E

On Wed, Aug 23, 2017 at 1:58 AM, Justin Mclean 
wrote:

> 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. https://www.apache.org/foundation/voting.html

Re: -1 or veto voting

[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. https://www.apache.org/foundation/voting.html