[DISCUSS] changing project name to apex-library

[Vlad Rozov <vr...@apache.org>]

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 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.
Changing the name is as disruptive to users as changing minor/patch 
version. I don't see a big difference in changing one line in pom.xml 
(version) vs changing 2 lines (version and artifact). There is a bigger 
change/disruption that does IMO require major version change and 
renaming project to use the single brand (Apache Apex) at the same time 
is beneficial both to the project and users. Changing package and major 
version will impact documentation in much bigger way compared to 
changing artifactId.
>
> 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.
There are many Apache projects that were around much longer than malhar 
and have not yet reached 3.x version even though they are also used in 
production and are considered more stable. Number of evolving packages 
and interfaces in malhar do not qualify it for 3.x or 4.x. IMO, version 
must be driven by the engineering/community, not by the marketing.
>
> 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 don't think it is as drastic as it looks to be. It was done in a past 
and is supported by all tools involved.
>
> 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.
It will be good to provide details why is it "a big deal". Why changing 
groupId was not a big deal and changing artifactId is a big deal?

I completely agree with the increasing adoption, but it comes from the 
quality, not from the quantity and whether version is 1.x, 3.x or 4.x 
does not change the quality of the library.
>
> Thanks
>
>
> On Wed, Aug 23, 2017 at 8:09 AM Vlad Rozov <vr...@apache.org> 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 <justin@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
>>
>> Thank you,
>>
>> Vlad
>>


Thank you,

Vlad

Re: [DISCUSS] changing project name to apex-library

[Vlad Rozov <vr...@apache.org>]

I don't see why requirement to commit changes to the master can or 
should be relaxed. The master is the code line that is and should be 
maintained by the community. The repository is not a collection of 
individual branches where I maintain my own branch and you maintain your 
own (it is an extreme, but that what the proposal to allow submissions 
to release-3 without a submission to the master eventually leads to). If 
a contributor does not want to make changes on the master, he/she can 
continue development on a private fork and release it (not as official 
Apache release). At this point there will be no guarantee that the 
changes would ever make into the Apache release (whether on master or 
any other branch). IMO, once the community moves to the next major 
release, all feature and not critical bug fixes should go into the 
master. If there is a critical bug fix, it must be fixed in the master 
and if it is critical enough, backported to whatever branch a 
contributor is willing to backport it to.

If there are code changes that only apply to release-3 branch and do not 
apply to the master (for whatever reason), this should be spelled out in 
JIRA and be considered an exception, not a rule.

Thank you,

Vlad

On 8/25/17 12:37, Pramod Immaneni wrote:
> On Fri, Aug 25, 2017 at 10:16 AM, Thomas Weise <th...@apache.org> wrote:
>
>> There is obviously disagreement with regard to version reset and you have
>> already voted for 4.0.
>>
> Yes and my position is still the same. I think there is a general consensus
> with 4.0, the additional concern/ask from community I believe, is because
> of the divergence as things go forward, to not burden the contributor from
> having to submit the PR to both master and release-3 and to relax the
> restriction by allowing submissions to go into release-3 without requiring
> they go into master. This would be different from what we do today.
>
> I think we can accomodate this for the following reasons. For the most part
> fixes and updates to existing operators/code would be cherry pickable onto
> master as is, with simple conflict resolution or with minor changes on top
> such as package name changes. If the contributor does not want to do the
> work the committer or the community can step in and do this at the same
> time when the original PR is merged or asynchronously if more time is
> needed so as to not block the original PR. We will need a way to track
> pending items and possibly we could do this in JIRA itself and additionally
> not close the JIRA till it is also fixed in master. The ones that are not
> trivial to port would be few in my opinion because as things go forward
> majority of the contributions will just go to master and for these few we
> can again rely on the community for help. Also, with the prevailing
> sentiment to do additional refactoring and cleanups in 4.x there may be no
> reason to port some of the changes in release-3 as they may no longer be
> applicable to 4.x.
>
>
>> A larger issue though is the attempt to stop any other proposal without
>> valid reason.
>>
>> If community members are willing to invest their efforts to improve the
>> project and provide the justification
>> for the changes then those that otherwise don't participate in discussions
>> or initiatives should not seek to prevent changes from happening.
>>
>> A project that is stuck in the past won't attract volunteers to work on it
>> and users to adopt it.
>>
> There are different users who have adopted the project at different stages
> or versions and have made investments on their side adopting the project
> and as the project continues to grow the number will only increase. Changes
> against the grain like these, affect them and we cannot trivialize it as
> merely a few lines code change or a pom.xml change. That may be a new
> development cycle for them and the associated cost. There may be
> documentation they need to change for their developers. We have to listen
> to community opinion and chart the best course forward.
>
> Thanks
>
>
>> Thomas
>>
>>
>> On Fri, Aug 25, 2017 at 9:57 AM, Pramod Immaneni <pr...@datatorrent.com>
>> wrote:
>>
>>> No, concerns for the changing the project name and version remain the
>> same.
>>> I think the current version numbering train and name are fine and prefer
>> we
>>> move forward and not backward by resetting things back to 1.x, which I
>>> believe is not accurate for the project. The name change is unnecessary,
>>> the name isn't broken that it needs to be fixed, it does not buy us much
>>> and causes unnecessary disruption for people who are already used to
>>> and malhar is already known out there. It is equivalent to asking for
>>> apex-core to be changed to apex-engine, engine is probably a better name
>>> but is it worth making the change, probably not, if it is not broke why
>> fix
>>> it.
>>>
>>> Thanks
>>>
>>> On Fri, Aug 25, 2017 at 9:01 AM, Vlad Rozov <vr...@apache.org> wrote:
>>>
>>>> How do we move from here? If all the concerns regarding version and
>>>> artifactId change are addressed we should move forward with the vote,
>> if
>>>> not, it will be good to raise them here rather than in the voting
>> thread.
>>>> Thank you,
>>>>
>>>> Vlad
>>>>
>>>>
>>>> On 8/24/17 10:26, Thomas Weise wrote:
>>>>
>>>>> On Thu, Aug 24, 2017 at 9:42 AM, Amol Kekre <am...@datatorrent.com>
>>> wrote:
>>>>> In terms of rebasing versions, there is no urgency in mimic-ing some
>> of
>>>>>> the
>>>>>> other projects. Apex has already be been versioned.
>>>>>>
>>>>> There is an expectation users have for a version number, which is
>>>>> different
>>>>> for 3.x or 1.x or 0.x. Apex library maturity is nowhere near 3.x. That
>>> was
>>>>> already discussed.
>>>>>
>>>>> What functional gain do
>>>>>
>>>>>> we have by changing versions, names? Functionality wise Apex users do
>>> not
>>>>>> gain anything. With regards to bumping to 4.X, we should wait for a
>>>>>> proposal/plan for a new functional api.
>>>>>>
>>>>>> Addition of such API does not require major version change. New API
>>> have
>>>>> been added and no major version change was done. Major version change
>> is
>>>>> for backward incompatible changes.
>>>>>
>>>>> Examples:
>>>>> - rename packages
>>>>> - remove deprecated code
>>>>> - relocate operators that were not designed for production use
>>>>> - change to functionality of operators
>>>>>
>>>>> There is an illusion of backward compatibility (which does not exist
>>>>> today). That cannot be used as justification to not make changes.
>>>>>
>>>>>
>>>>> On Wed, Aug 23, 2017 at 10:26 AM, Vlad Rozov <vr...@apache.org>
>> wrote:
>>>>>> 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 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.
>>>>>>>>
>>>>>>>> Changing the name is as disruptive to users as changing minor/patch
>>>>>>> version. I don't see a big difference in changing one line in
>> pom.xml
>>>>>>> (version) vs changing 2 lines (version and artifact). There is a
>>> bigger
>>>>>>> change/disruption that does IMO require major version change and
>>>>>>> renaming
>>>>>>> project to use the single brand (Apache Apex) at the same time is
>>>>>>> beneficial both to the project and users. Changing package and major
>>>>>>> version will impact documentation in much bigger way compared to
>>>>>>> changing
>>>>>>> artifactId.
>>>>>>>
>>>>>>> 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.
>>>>>>>> There are many Apache projects that were around much longer than
>>> malhar
>>>>>>> and have not yet reached 3.x version even though they are also used
>> in
>>>>>>> production and are considered more stable. Number of evolving
>> packages
>>>>>> and
>>>>>>
>>>>>>> interfaces in malhar do not qualify it for 3.x or 4.x. IMO, version
>>> must
>>>>>> be
>>>>>>
>>>>>>> driven by the engineering/community, not by the marketing.
>>>>>>>
>>>>>>> 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 don't think it is as drastic as it looks to be. It was done in a
>>> past
>>>>>>> and is supported by all tools involved.
>>>>>>>
>>>>>>> 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.
>>>>>>>> It will be good to provide details why is it "a big deal". Why
>>> changing
>>>>>>> groupId was not a big deal and changing artifactId is a big deal?
>>>>>>>
>>>>>>> I completely agree with the increasing adoption, but it comes from
>> the
>>>>>>> quality, not from the quantity and whether version is 1.x, 3.x or
>> 4.x
>>>>>> does
>>>>>>
>>>>>>> not change the quality of the library.
>>>>>>>
>>>>>>> Thanks
>>>>>>>>
>>>>>>>> On Wed, Aug 23, 2017 at 8:09 AM Vlad Rozov <vr...@apache.org>
>>> 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 <
>>>>>>>>>> justin@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
>>>>>>>>>>>
>>>>>>>>>>> Thank you,
>>>>>>>>> Vlad
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Thank you,
>>>>>>> Vlad
>>>>>>>
>>>>>>>
>>>> Thank you,
>>>>
>>>> Vlad
>>>>


Thank you,

Vlad

Re: [DISCUSS] changing project name to apex-library

[Vlad Rozov <vr...@apache.org>]

The gain is consistency and meeting/setting up expectations on the 
project quality/maturity.

Thank you,

Vlad

On 8/24/17 09:42, Amol Kekre wrote:
> In terms of rebasing versions, there is no urgency in mimic-ing some of the
> other projects. Apex has already be been versioned. What functional gain do
> we have by changing versions, names? Functionality wise Apex users do not
> gain anything. With regards to bumping to 4.X, we should wait for a
> proposal/plan for a new functional api.
>
> Thks,
> Amol
>
>
> E:amol@datatorrent.com | M: 510-449-2606 | Twitter: @*amolhkekre*
>
> www.datatorrent.com
>
>
> On Wed, Aug 23, 2017 at 10:26 AM, Vlad Rozov <vr...@apache.org> wrote:
>
>> 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 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.
>>>
>> Changing the name is as disruptive to users as changing minor/patch
>> version. I don't see a big difference in changing one line in pom.xml
>> (version) vs changing 2 lines (version and artifact). There is a bigger
>> change/disruption that does IMO require major version change and renaming
>> project to use the single brand (Apache Apex) at the same time is
>> beneficial both to the project and users. Changing package and major
>> version will impact documentation in much bigger way compared to changing
>> artifactId.
>>
>>> 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.
>>>
>> There are many Apache projects that were around much longer than malhar
>> and have not yet reached 3.x version even though they are also used in
>> production and are considered more stable. Number of evolving packages and
>> interfaces in malhar do not qualify it for 3.x or 4.x. IMO, version must be
>> driven by the engineering/community, not by the marketing.
>>
>>> 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 don't think it is as drastic as it looks to be. It was done in a past
>> and is supported by all tools involved.
>>
>>> 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.
>>>
>> It will be good to provide details why is it "a big deal". Why changing
>> groupId was not a big deal and changing artifactId is a big deal?
>>
>> I completely agree with the increasing adoption, but it comes from the
>> quality, not from the quantity and whether version is 1.x, 3.x or 4.x does
>> not change the quality of the library.
>>
>>> Thanks
>>>
>>>
>>> On Wed, Aug 23, 2017 at 8:09 AM Vlad Rozov <vr...@apache.org> 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 <
>>>>> justin@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
>>>>>>
>>>> Thank you,
>>>>
>>>> Vlad
>>>>
>>>>
>> Thank you,
>>
>> Vlad
>>


Thank you,

Vlad

Re: [DISCUSS] changing project name to apex-library

[Thomas Weise <th...@apache.org>]

Which specific concern has not been addressed?

The need to for the change has been discussed and no valid reason why it
cannot be done was provided.


On Fri, Aug 25, 2017 at 9:17 AM, Amol Kekre <am...@datatorrent.com> wrote:

> Vlad,
> Concerns have not been addressed. There is a disconnect on the need to do
> this now, and then on how to do so.
>
> Thks,
> Amol
>
>
>
> E:amol@datatorrent.com | M: 510-449-2606 | Twitter: @*amolhkekre*
>
> www.datatorrent.com
>
>
> On Fri, Aug 25, 2017 at 9:01 AM, Vlad Rozov <vr...@apache.org> wrote:
>
> > How do we move from here? If all the concerns regarding version and
> > artifactId change are addressed we should move forward with the vote, if
> > not, it will be good to raise them here rather than in the voting thread.
> >
> > Thank you,
> >
> > Vlad
> >
> >
> > On 8/24/17 10:26, Thomas Weise wrote:
> >
> >> On Thu, Aug 24, 2017 at 9:42 AM, Amol Kekre <am...@datatorrent.com>
> wrote:
> >>
> >> In terms of rebasing versions, there is no urgency in mimic-ing some of
> >>> the
> >>> other projects. Apex has already be been versioned.
> >>>
> >>
> >> There is an expectation users have for a version number, which is
> >> different
> >> for 3.x or 1.x or 0.x. Apex library maturity is nowhere near 3.x. That
> was
> >> already discussed.
> >>
> >> What functional gain do
> >>
> >>> we have by changing versions, names? Functionality wise Apex users do
> not
> >>> gain anything. With regards to bumping to 4.X, we should wait for a
> >>> proposal/plan for a new functional api.
> >>>
> >>> Addition of such API does not require major version change. New API
> have
> >> been added and no major version change was done. Major version change is
> >> for backward incompatible changes.
> >>
> >> Examples:
> >> - rename packages
> >> - remove deprecated code
> >> - relocate operators that were not designed for production use
> >> - change to functionality of operators
> >>
> >> There is an illusion of backward compatibility (which does not exist
> >> today). That cannot be used as justification to not make changes.
> >>
> >>
> >> On Wed, Aug 23, 2017 at 10:26 AM, Vlad Rozov <vr...@apache.org> wrote:
> >>>
> >>> 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 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.
> >>>>>
> >>>>> Changing the name is as disruptive to users as changing minor/patch
> >>>> version. I don't see a big difference in changing one line in pom.xml
> >>>> (version) vs changing 2 lines (version and artifact). There is a
> bigger
> >>>> change/disruption that does IMO require major version change and
> >>>> renaming
> >>>> project to use the single brand (Apache Apex) at the same time is
> >>>> beneficial both to the project and users. Changing package and major
> >>>> version will impact documentation in much bigger way compared to
> >>>> changing
> >>>> artifactId.
> >>>>
> >>>> 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.
> >>>>>
> >>>>> There are many Apache projects that were around much longer than
> malhar
> >>>> and have not yet reached 3.x version even though they are also used in
> >>>> production and are considered more stable. Number of evolving packages
> >>>>
> >>> and
> >>>
> >>>> interfaces in malhar do not qualify it for 3.x or 4.x. IMO, version
> must
> >>>>
> >>> be
> >>>
> >>>> driven by the engineering/community, not by the marketing.
> >>>>
> >>>> 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 don't think it is as drastic as it looks to be. It was done in a
> past
> >>>> and is supported by all tools involved.
> >>>>
> >>>> 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.
> >>>>>
> >>>>> It will be good to provide details why is it "a big deal". Why
> changing
> >>>> groupId was not a big deal and changing artifactId is a big deal?
> >>>>
> >>>> I completely agree with the increasing adoption, but it comes from the
> >>>> quality, not from the quantity and whether version is 1.x, 3.x or 4.x
> >>>>
> >>> does
> >>>
> >>>> not change the quality of the library.
> >>>>
> >>>> Thanks
> >>>>>
> >>>>>
> >>>>> On Wed, Aug 23, 2017 at 8:09 AM Vlad Rozov <vr...@apache.org>
> 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 <
> >>>>>>> justin@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
> >>>>>>>>
> >>>>>>>> Thank you,
> >>>>>>
> >>>>>> Vlad
> >>>>>>
> >>>>>>
> >>>>>> Thank you,
> >>>>
> >>>> Vlad
> >>>>
> >>>>
> >
> > Thank you,
> >
> > Vlad
> >
>

Re: [DISCUSS] changing project name to apex-library

[Amol Kekre <am...@datatorrent.com>]

Vlad,
Concerns have not been addressed. There is a disconnect on the need to do
this now, and then on how to do so.

Thks,
Amol



E:amol@datatorrent.com | M: 510-449-2606 | Twitter: @*amolhkekre*

www.datatorrent.com


On Fri, Aug 25, 2017 at 9:01 AM, Vlad Rozov <vr...@apache.org> wrote:

> How do we move from here? If all the concerns regarding version and
> artifactId change are addressed we should move forward with the vote, if
> not, it will be good to raise them here rather than in the voting thread.
>
> Thank you,
>
> Vlad
>
>
> On 8/24/17 10:26, Thomas Weise wrote:
>
>> On Thu, Aug 24, 2017 at 9:42 AM, Amol Kekre <am...@datatorrent.com> wrote:
>>
>> In terms of rebasing versions, there is no urgency in mimic-ing some of
>>> the
>>> other projects. Apex has already be been versioned.
>>>
>>
>> There is an expectation users have for a version number, which is
>> different
>> for 3.x or 1.x or 0.x. Apex library maturity is nowhere near 3.x. That was
>> already discussed.
>>
>> What functional gain do
>>
>>> we have by changing versions, names? Functionality wise Apex users do not
>>> gain anything. With regards to bumping to 4.X, we should wait for a
>>> proposal/plan for a new functional api.
>>>
>>> Addition of such API does not require major version change. New API have
>> been added and no major version change was done. Major version change is
>> for backward incompatible changes.
>>
>> Examples:
>> - rename packages
>> - remove deprecated code
>> - relocate operators that were not designed for production use
>> - change to functionality of operators
>>
>> There is an illusion of backward compatibility (which does not exist
>> today). That cannot be used as justification to not make changes.
>>
>>
>> On Wed, Aug 23, 2017 at 10:26 AM, Vlad Rozov <vr...@apache.org> wrote:
>>>
>>> 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 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.
>>>>>
>>>>> Changing the name is as disruptive to users as changing minor/patch
>>>> version. I don't see a big difference in changing one line in pom.xml
>>>> (version) vs changing 2 lines (version and artifact). There is a bigger
>>>> change/disruption that does IMO require major version change and
>>>> renaming
>>>> project to use the single brand (Apache Apex) at the same time is
>>>> beneficial both to the project and users. Changing package and major
>>>> version will impact documentation in much bigger way compared to
>>>> changing
>>>> artifactId.
>>>>
>>>> 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.
>>>>>
>>>>> There are many Apache projects that were around much longer than malhar
>>>> and have not yet reached 3.x version even though they are also used in
>>>> production and are considered more stable. Number of evolving packages
>>>>
>>> and
>>>
>>>> interfaces in malhar do not qualify it for 3.x or 4.x. IMO, version must
>>>>
>>> be
>>>
>>>> driven by the engineering/community, not by the marketing.
>>>>
>>>> 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 don't think it is as drastic as it looks to be. It was done in a past
>>>> and is supported by all tools involved.
>>>>
>>>> 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.
>>>>>
>>>>> It will be good to provide details why is it "a big deal". Why changing
>>>> groupId was not a big deal and changing artifactId is a big deal?
>>>>
>>>> I completely agree with the increasing adoption, but it comes from the
>>>> quality, not from the quantity and whether version is 1.x, 3.x or 4.x
>>>>
>>> does
>>>
>>>> not change the quality of the library.
>>>>
>>>> Thanks
>>>>>
>>>>>
>>>>> On Wed, Aug 23, 2017 at 8:09 AM Vlad Rozov <vr...@apache.org> 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 <
>>>>>>> justin@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
>>>>>>>>
>>>>>>>> Thank you,
>>>>>>
>>>>>> Vlad
>>>>>>
>>>>>>
>>>>>> Thank you,
>>>>
>>>> Vlad
>>>>
>>>>
>
> Thank you,
>
> Vlad
>

Re: [DISCUSS] changing project name to apex-library

[Thomas Weise <th...@apache.org>]

On Mon, Aug 28, 2017 at 12:41 AM, Pramod Immaneni <pr...@datatorrent.com>
wrote:


> > > It could easily
> > > be argued the other way, that it is easy to propose wholesale changes
> > > without much thought to what it would take to support existing users
> when
> > > there is no obligation to support them like a vendor may have.
> >
> >
> > How so? I will argue that the opposite is true. I don't want to repeat
> > things again and again. You know that I proposed an option based on 3.x
> > (and took the time to implement it) that would have required no change to
> > the user and not even a major version change. Now are debating major
> > version change, which no existing user is obligated to adopt, users can
> > continue with what they have and the vendor can continue to support 3.x.
> >
>
> The implementation, while did consider backward compatibility, provided a
> frozen version of the project and would require users to change their code
> in order to benefit from newer fixes and updates to existing operators.
> While appreciating the approach, I did note these shortcomings in the
> discussions in original discussion and the subsquent one and asked if a
> similar approach could be applied in a way that it would be possible to
> allow existing applications to benefit from future updates in the same
> major version without code changes. This is not trivial and when I saw
> there was no appetite to do this, I supported 4.x as the alternative.
>
>
Please refer to your original statement regarding wholesale changes. None
of the proposals under discussion propose wholesale changes without
considering existing users, that would be a false allegation.


> > Let's keep in mind that today there are not many users ("many" is
> > subjective). It is further a misrepresentation to claim that the
> community
> > wanting to make changes negatively affects users. I will argue the
> opposite
> > is true, the changes that are proposed will make it easier for new users
> to
> > adopt and build applications.
> >
>
> This is a very broad and incorrect interpretation of the original statement
> and it does not say or translate to "community
> wanting to make changes negatively affects users". It gives one
> interpretation of the original proposal of changing the package paths
> without providing wrappers that will remain compatible with older versions
> for at least some transitional period (no frozen older release is not the
> same). It is not what the community as a whole wants, so I wouldn't call it
> a community want either.



Should have been a separate paragraph. This part is actually not related to
your earlier statement regarding "community ask" but with regard to
repeated claims by a few that changes discussed negatively affect users.
That has already been addressed and there is nothing to back it up. As such
it is an invalid reason in voting -1.


>

Re: [DISCUSS] changing project name to apex-library

[Pramod Immaneni <pr...@datatorrent.com>]

On Sun, Aug 27, 2017 at 7:21 PM, Thomas Weise <th...@apache.org> wrote:

> I think you have been consistent in your position. However, we cannot claim
> something is a community concern unless that is the case.
>
> On Sun, Aug 27, 2017 at 5:37 PM, Pramod Immaneni <pr...@datatorrent.com>
> wrote:
>
> >
> > It could easily
> > be argued the other way, that it is easy to propose wholesale changes
> > without much thought to what it would take to support existing users when
> > there is no obligation to support them like a vendor may have.
>
>
> How so? I will argue that the opposite is true. I don't want to repeat
> things again and again. You know that I proposed an option based on 3.x
> (and took the time to implement it) that would have required no change to
> the user and not even a major version change. Now are debating major
> version change, which no existing user is obligated to adopt, users can
> continue with what they have and the vendor can continue to support 3.x.
>

The implementation, while did consider backward compatibility, provided a
frozen version of the project and would require users to change their code
in order to benefit from newer fixes and updates to existing operators.
While appreciating the approach, I did note these shortcomings in the
discussions in original discussion and the subsquent one and asked if a
similar approach could be applied in a way that it would be possible to
allow existing applications to benefit from future updates in the same
major version without code changes. This is not trivial and when I saw
there was no appetite to do this, I supported 4.x as the alternative.


> Let's keep in mind that today there are not many users ("many" is
> subjective). It is further a misrepresentation to claim that the community
> wanting to make changes negatively affects users. I will argue the opposite
> is true, the changes that are proposed will make it easier for new users to
> adopt and build applications.
>

This is a very broad and incorrect interpretation of the original statement
and it does not say or translate to "community
wanting to make changes negatively affects users". It gives one
interpretation of the original proposal of changing the package paths
without providing wrappers that will remain compatible with older versions
for at least some transitional period (no frozen older release is not the
same). It is not what the community as a whole wants, so I wouldn't call it
a community want either.


> >
> >
> > Yes nothing would prevent contributors from submitting the changes to
> > master simultaneously and should be encouraged. I am trying to figure out
> > the best way to accomodate the ask where the contributors be not required
> > to do so when they cannot or don't want to do so and to not block those
> > contributions. I don't know if this will change the -1 votes but hoping
> > folks can discuss this.
> >
>
> If it is purely a vendor interest and not a community interest, then it is
> also possible to apply such changes to the fork. This has been done in the
> past. I see a risk that we are discussing something that may not even
> become relevant, looking at current contributions and type of changes.
>

Then lets allow it for the specific release-3 branch and see how it goes.
This might assuage the concerns of those who raised them and help them come
around to going for a 4.x now.

Thanks

Re: [DISCUSS] changing project name to apex-library

[Thomas Weise <th...@apache.org>]

I think you have been consistent in your position. However, we cannot claim
something is a community concern unless that is the case.

On Sun, Aug 27, 2017 at 5:37 PM, Pramod Immaneni <pr...@datatorrent.com>
wrote:

>
> It could easily
> be argued the other way, that it is easy to propose wholesale changes
> without much thought to what it would take to support existing users when
> there is no obligation to support them like a vendor may have.


How so? I will argue that the opposite is true. I don't want to repeat
things again and again. You know that I proposed an option based on 3.x
(and took the time to implement it) that would have required no change to
the user and not even a major version change. Now are debating major
version change, which no existing user is obligated to adopt, users can
continue with what they have and the vendor can continue to support 3.x.
Let's keep in mind that today there are not many users ("many" is
subjective). It is further a misrepresentation to claim that the community
wanting to make changes negatively affects users. I will argue the opposite
is true, the changes that are proposed will make it easier for new users to
adopt and build applications.

>
>
> Yes nothing would prevent contributors from submitting the changes to
> master simultaneously and should be encouraged. I am trying to figure out
> the best way to accomodate the ask where the contributors be not required
> to do so when they cannot or don't want to do so and to not block those
> contributions. I don't know if this will change the -1 votes but hoping
> folks can discuss this.
>

If it is purely a vendor interest and not a community interest, then it is
also possible to apply such changes to the fork. This has been done in the
past. I see a risk that we are discussing something that may not even
become relevant, looking at current contributions and type of changes.

Re: [DISCUSS] changing project name to apex-library

[Pramod Immaneni <pr...@datatorrent.com>]

On Sun, Aug 27, 2017 at 3:16 PM, Thomas Weise <th...@apache.org> wrote:

> On Fri, Aug 25, 2017 at 12:37 PM, Pramod Immaneni <pr...@datatorrent.com>
> wrote:
>
> > I think there is a general consensus
> > with 4.0, the additional concern/ask from community I believe, is because
> > of the divergence as things go forward, to not burden the contributor
> from
> > having to submit the PR to both master and release-3 and to relax the
> > restriction by allowing submissions to go into release-3 without
> requiring
> > they go into master. This would be different from what we do today.
> >
> >
> It is not a "concern/ask from community". It was a demand made by an
> individual. We cannot confuse a specific individual or a specific company
> with "community". By looking at discussion, voting and affiliation, I would
> in fact argue that it can be seen as attempt to control the project by a
> vendor, that runs afoul project independence.
>

I can only say this, I try to look at what is said on its own merit and try
not to ascribe intentions nefarious or otherwise to them, whether it is
from someone from my affliation or from a different affiliation. I
encourage others to do the same. If you look closely there are different
positions from folks even within the affiliation/vendor that is being
referred to. I myself, when the discussion started, asking for sticking
with 3.x and maintaining backward compatibility initially have moved to the
4.x,release-3 approach after realizing the work to maintain compatibility
is not trivial and cannot contribute to that work myself. It's no secret
there is one main (if not only) vendor for apex and if there were more we
might have very well seen similar concerns raised by them. It could easily
be argued the other way, that it is easy to propose wholesale changes
without much thought to what it would take to support existing users when
there is no obligation to support them like a vendor may have. What I am
suggesting does not hold the project back from moving forward to satisfy a
group of community members and still tries to address their concerns. I
suggest this line of argument is non-productive, if not divisive, and we
don't go there.


>
> I don't see why changes should not be submitted to master as it is done
> now. Since you already say that only a few changes would be difficult to
> cherry-pick/port, such cases can be considered as exceptions.
>

Yes nothing would prevent contributors from submitting the changes to
master simultaneously and should be encouraged. I am trying to figure out
the best way to accomodate the ask where the contributors be not required
to do so when they cannot or don't want to do so and to not block those
contributions. I don't know if this will change the -1 votes but hoping
folks can discuss this.

Thanks

Re: [DISCUSS] changing project name to apex-library

[Thomas Weise <th...@apache.org>]

On Fri, Aug 25, 2017 at 12:37 PM, Pramod Immaneni <pr...@datatorrent.com>
wrote:

> I think there is a general consensus
> with 4.0, the additional concern/ask from community I believe, is because
> of the divergence as things go forward, to not burden the contributor from
> having to submit the PR to both master and release-3 and to relax the
> restriction by allowing submissions to go into release-3 without requiring
> they go into master. This would be different from what we do today.
>
>
It is not a "concern/ask from community". It was a demand made by an
individual. We cannot confuse a specific individual or a specific company
with "community". By looking at discussion, voting and affiliation, I would
in fact argue that it can be seen as attempt to control the project by a
vendor, that runs afoul project independence.

I don't see why changes should not be submitted to master as it is done
now. Since you already say that only a few changes would be difficult to
cherry-pick/port, such cases can be considered as exceptions.

Thomas

Re: [DISCUSS] changing project name to apex-library

[Pramod Immaneni <pr...@datatorrent.com>]

On Fri, Aug 25, 2017 at 10:16 AM, Thomas Weise <th...@apache.org> wrote:

> There is obviously disagreement with regard to version reset and you have
> already voted for 4.0.
>

Yes and my position is still the same. I think there is a general consensus
with 4.0, the additional concern/ask from community I believe, is because
of the divergence as things go forward, to not burden the contributor from
having to submit the PR to both master and release-3 and to relax the
restriction by allowing submissions to go into release-3 without requiring
they go into master. This would be different from what we do today.

I think we can accomodate this for the following reasons. For the most part
fixes and updates to existing operators/code would be cherry pickable onto
master as is, with simple conflict resolution or with minor changes on top
such as package name changes. If the contributor does not want to do the
work the committer or the community can step in and do this at the same
time when the original PR is merged or asynchronously if more time is
needed so as to not block the original PR. We will need a way to track
pending items and possibly we could do this in JIRA itself and additionally
not close the JIRA till it is also fixed in master. The ones that are not
trivial to port would be few in my opinion because as things go forward
majority of the contributions will just go to master and for these few we
can again rely on the community for help. Also, with the prevailing
sentiment to do additional refactoring and cleanups in 4.x there may be no
reason to port some of the changes in release-3 as they may no longer be
applicable to 4.x.


>
> A larger issue though is the attempt to stop any other proposal without
> valid reason.
>
> If community members are willing to invest their efforts to improve the
> project and provide the justification
> for the changes then those that otherwise don't participate in discussions
> or initiatives should not seek to prevent changes from happening.
>
> A project that is stuck in the past won't attract volunteers to work on it
> and users to adopt it.
>

There are different users who have adopted the project at different stages
or versions and have made investments on their side adopting the project
and as the project continues to grow the number will only increase. Changes
against the grain like these, affect them and we cannot trivialize it as
merely a few lines code change or a pom.xml change. That may be a new
development cycle for them and the associated cost. There may be
documentation they need to change for their developers. We have to listen
to community opinion and chart the best course forward.

Thanks


>
> Thomas
>
>
> On Fri, Aug 25, 2017 at 9:57 AM, Pramod Immaneni <pr...@datatorrent.com>
> wrote:
>
> > No, concerns for the changing the project name and version remain the
> same.
> > I think the current version numbering train and name are fine and prefer
> we
> > move forward and not backward by resetting things back to 1.x, which I
> > believe is not accurate for the project. The name change is unnecessary,
> > the name isn't broken that it needs to be fixed, it does not buy us much
> > and causes unnecessary disruption for people who are already used to
> > and malhar is already known out there. It is equivalent to asking for
> > apex-core to be changed to apex-engine, engine is probably a better name
> > but is it worth making the change, probably not, if it is not broke why
> fix
> > it.
> >
> > Thanks
> >
> > On Fri, Aug 25, 2017 at 9:01 AM, Vlad Rozov <vr...@apache.org> wrote:
> >
> > > How do we move from here? If all the concerns regarding version and
> > > artifactId change are addressed we should move forward with the vote,
> if
> > > not, it will be good to raise them here rather than in the voting
> thread.
> > >
> > > Thank you,
> > >
> > > Vlad
> > >
> > >
> > > On 8/24/17 10:26, Thomas Weise wrote:
> > >
> > >> On Thu, Aug 24, 2017 at 9:42 AM, Amol Kekre <am...@datatorrent.com>
> > wrote:
> > >>
> > >> In terms of rebasing versions, there is no urgency in mimic-ing some
> of
> > >>> the
> > >>> other projects. Apex has already be been versioned.
> > >>>
> > >>
> > >> There is an expectation users have for a version number, which is
> > >> different
> > >> for 3.x or 1.x or 0.x. Apex library maturity is nowhere near 3.x. That
> > was
> > >> already discussed.
> > >>
> > >> What functional gain do
> > >>
> > >>> we have by changing versions, names? Functionality wise Apex users do
> > not
> > >>> gain anything. With regards to bumping to 4.X, we should wait for a
> > >>> proposal/plan for a new functional api.
> > >>>
> > >>> Addition of such API does not require major version change. New API
> > have
> > >> been added and no major version change was done. Major version change
> is
> > >> for backward incompatible changes.
> > >>
> > >> Examples:
> > >> - rename packages
> > >> - remove deprecated code
> > >> - relocate operators that were not designed for production use
> > >> - change to functionality of operators
> > >>
> > >> There is an illusion of backward compatibility (which does not exist
> > >> today). That cannot be used as justification to not make changes.
> > >>
> > >>
> > >> On Wed, Aug 23, 2017 at 10:26 AM, Vlad Rozov <vr...@apache.org>
> wrote:
> > >>>
> > >>> 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 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.
> > >>>>>
> > >>>>> Changing the name is as disruptive to users as changing minor/patch
> > >>>> version. I don't see a big difference in changing one line in
> pom.xml
> > >>>> (version) vs changing 2 lines (version and artifact). There is a
> > bigger
> > >>>> change/disruption that does IMO require major version change and
> > >>>> renaming
> > >>>> project to use the single brand (Apache Apex) at the same time is
> > >>>> beneficial both to the project and users. Changing package and major
> > >>>> version will impact documentation in much bigger way compared to
> > >>>> changing
> > >>>> artifactId.
> > >>>>
> > >>>> 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.
> > >>>>>
> > >>>>> There are many Apache projects that were around much longer than
> > malhar
> > >>>> and have not yet reached 3.x version even though they are also used
> in
> > >>>> production and are considered more stable. Number of evolving
> packages
> > >>>>
> > >>> and
> > >>>
> > >>>> interfaces in malhar do not qualify it for 3.x or 4.x. IMO, version
> > must
> > >>>>
> > >>> be
> > >>>
> > >>>> driven by the engineering/community, not by the marketing.
> > >>>>
> > >>>> 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 don't think it is as drastic as it looks to be. It was done in a
> > past
> > >>>> and is supported by all tools involved.
> > >>>>
> > >>>> 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.
> > >>>>>
> > >>>>> It will be good to provide details why is it "a big deal". Why
> > changing
> > >>>> groupId was not a big deal and changing artifactId is a big deal?
> > >>>>
> > >>>> I completely agree with the increasing adoption, but it comes from
> the
> > >>>> quality, not from the quantity and whether version is 1.x, 3.x or
> 4.x
> > >>>>
> > >>> does
> > >>>
> > >>>> not change the quality of the library.
> > >>>>
> > >>>> Thanks
> > >>>>>
> > >>>>>
> > >>>>> On Wed, Aug 23, 2017 at 8:09 AM Vlad Rozov <vr...@apache.org>
> > 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 <
> > >>>>>>> justin@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
> > >>>>>>>>
> > >>>>>>>> Thank you,
> > >>>>>>
> > >>>>>> Vlad
> > >>>>>>
> > >>>>>>
> > >>>>>> Thank you,
> > >>>>
> > >>>> Vlad
> > >>>>
> > >>>>
> > >
> > > Thank you,
> > >
> > > Vlad
> > >
> >
>

Re: [DISCUSS] changing project name to apex-library

[Thomas Weise <th...@apache.org>]

There is obviously disagreement with regard to version reset and you have
already voted for 4.0.

A larger issue though is the attempt to stop any other proposal without
valid reason.

If community members are willing to invest their efforts to improve the
project and provide the justification
for the changes then those that otherwise don't participate in discussions
or initiatives should not seek to prevent changes from happening.

A project that is stuck in the past won't attract volunteers to work on it
and users to adopt it.

Thomas


On Fri, Aug 25, 2017 at 9:57 AM, Pramod Immaneni <pr...@datatorrent.com>
wrote:

> No, concerns for the changing the project name and version remain the same.
> I think the current version numbering train and name are fine and prefer we
> move forward and not backward by resetting things back to 1.x, which I
> believe is not accurate for the project. The name change is unnecessary,
> the name isn't broken that it needs to be fixed, it does not buy us much
> and causes unnecessary disruption for people who are already used to
> and malhar is already known out there. It is equivalent to asking for
> apex-core to be changed to apex-engine, engine is probably a better name
> but is it worth making the change, probably not, if it is not broke why fix
> it.
>
> Thanks
>
> On Fri, Aug 25, 2017 at 9:01 AM, Vlad Rozov <vr...@apache.org> wrote:
>
> > How do we move from here? If all the concerns regarding version and
> > artifactId change are addressed we should move forward with the vote, if
> > not, it will be good to raise them here rather than in the voting thread.
> >
> > Thank you,
> >
> > Vlad
> >
> >
> > On 8/24/17 10:26, Thomas Weise wrote:
> >
> >> On Thu, Aug 24, 2017 at 9:42 AM, Amol Kekre <am...@datatorrent.com>
> wrote:
> >>
> >> In terms of rebasing versions, there is no urgency in mimic-ing some of
> >>> the
> >>> other projects. Apex has already be been versioned.
> >>>
> >>
> >> There is an expectation users have for a version number, which is
> >> different
> >> for 3.x or 1.x or 0.x. Apex library maturity is nowhere near 3.x. That
> was
> >> already discussed.
> >>
> >> What functional gain do
> >>
> >>> we have by changing versions, names? Functionality wise Apex users do
> not
> >>> gain anything. With regards to bumping to 4.X, we should wait for a
> >>> proposal/plan for a new functional api.
> >>>
> >>> Addition of such API does not require major version change. New API
> have
> >> been added and no major version change was done. Major version change is
> >> for backward incompatible changes.
> >>
> >> Examples:
> >> - rename packages
> >> - remove deprecated code
> >> - relocate operators that were not designed for production use
> >> - change to functionality of operators
> >>
> >> There is an illusion of backward compatibility (which does not exist
> >> today). That cannot be used as justification to not make changes.
> >>
> >>
> >> On Wed, Aug 23, 2017 at 10:26 AM, Vlad Rozov <vr...@apache.org> wrote:
> >>>
> >>> 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 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.
> >>>>>
> >>>>> Changing the name is as disruptive to users as changing minor/patch
> >>>> version. I don't see a big difference in changing one line in pom.xml
> >>>> (version) vs changing 2 lines (version and artifact). There is a
> bigger
> >>>> change/disruption that does IMO require major version change and
> >>>> renaming
> >>>> project to use the single brand (Apache Apex) at the same time is
> >>>> beneficial both to the project and users. Changing package and major
> >>>> version will impact documentation in much bigger way compared to
> >>>> changing
> >>>> artifactId.
> >>>>
> >>>> 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.
> >>>>>
> >>>>> There are many Apache projects that were around much longer than
> malhar
> >>>> and have not yet reached 3.x version even though they are also used in
> >>>> production and are considered more stable. Number of evolving packages
> >>>>
> >>> and
> >>>
> >>>> interfaces in malhar do not qualify it for 3.x or 4.x. IMO, version
> must
> >>>>
> >>> be
> >>>
> >>>> driven by the engineering/community, not by the marketing.
> >>>>
> >>>> 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 don't think it is as drastic as it looks to be. It was done in a
> past
> >>>> and is supported by all tools involved.
> >>>>
> >>>> 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.
> >>>>>
> >>>>> It will be good to provide details why is it "a big deal". Why
> changing
> >>>> groupId was not a big deal and changing artifactId is a big deal?
> >>>>
> >>>> I completely agree with the increasing adoption, but it comes from the
> >>>> quality, not from the quantity and whether version is 1.x, 3.x or 4.x
> >>>>
> >>> does
> >>>
> >>>> not change the quality of the library.
> >>>>
> >>>> Thanks
> >>>>>
> >>>>>
> >>>>> On Wed, Aug 23, 2017 at 8:09 AM Vlad Rozov <vr...@apache.org>
> 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 <
> >>>>>>> justin@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
> >>>>>>>>
> >>>>>>>> Thank you,
> >>>>>>
> >>>>>> Vlad
> >>>>>>
> >>>>>>
> >>>>>> Thank you,
> >>>>
> >>>> Vlad
> >>>>
> >>>>
> >
> > Thank you,
> >
> > Vlad
> >
>

Re: [DISCUSS] changing project name to apex-library

[Vlad Rozov <v....@gmail.com>]

On 8/27/17 16:09, Pramod Immaneni wrote:
> On Sun, Aug 27, 2017 at 1:41 PM, Vlad Rozov <vr...@apache.org> wrote:
>
>> 1.x may not be accurate, but 4.x (as well as 3.x, 2.x or 0.x) may not be
>> accurate either. I don't see why 4.x is more accurate than 1.x. In any case
>> this is personal preference and there is no *technical* justification not
>> to go with 1.x once the artifactId is also changed.
>>
> 4.x would be much better justified than 1.x because we are right now on 3.8
> dev, thinking about making incompatible changes and combined with the fact
> that we haven't been on 3.x only for a short period, logic would dictate
> going to the next major version.
It is all subjective. I don't think that the current 3.8 version is 
accurate and properly reflects quality and maturity of the library.
>
>
>> -1 in a discussion thread is different from -1 in the voting thread. In a
>> discussion thread it means "I strongly prefer/recommend that the community
>> does not go that way". In the voting thread it means "I request that the
>> changes are not implemented" (veto). For the veto to be valid, there must
>> be *technical* reason not to move forward. In this particular case I would
>> consider "maven does not support artifactId change" as a valid technical
>> reason for -1.
>
> By that logic there is no techical issue with renaming apex-core or
> apex-malhar to apex-<anything> because almost anything will technically
> work with maven and other tools. That being the only criteria doesn't make
> sense and is not the case. One of the mentors noted the same in one of the
> threads. There is no agreement that the project name should be changed and
> so with justifiable reasons.
If there is a reason to change apex to apex-<anything>, so the majority 
of the community decides to make the change, I, as an individual 
contributor/committer/PMC member, can't stop it by vetoing the change. 
Yes, there is no agreement that the project name should be changed, but 
also there is no agreement that it should continue under the same name. 
A few members of the community including several PMCs prefer to change 
the name and the version.
>
>> A fact that somebody refers to a project as Malhar instead of Apache Apex
>> is not a valid technical justification. Up to this point no valid technical
>> justification was provided to stop artifactId and version change. I don't
>> take "cost" as a valid technical justification either. There was a large
>> cost to enforce checkstyle, but benefits from implementing checkstyle were
>> definitely worth the cost.
>>
> That is a incorrect analogy, checkstyle was internal. It did not impact
> users. What you are asking for, may not impact devs who are developing apex
> as much but it impacts users and hence has "cost" that I detailed in my
> earlier email and if it wasn't clear from my earlier emails is not good for
> the continued adoption of the project. Regarding the technical
> justification see my comment above.
We already discussed this. Externally, upgrade to 4.0 that you don't 
seem to object is equivalent to artifact change combined with the 
version change to 1.0.

For example netty was renamed to netty-all 
(https://mvnrepository.com/artifact/io.netty/netty) and netty adoption 
(https://mvnrepository.com/artifact/io.netty/netty/usages) is the order 
of magnitude more than Malhar adoption 
(https://mvnrepository.com/artifact/org.apache.apex/malhar-library/usages). 
A single brand that is better for the future adoption is the 
justification for the internal cost of the rename.
>
> Thanks
>
>> Thank you,
>>
>> Vlad
>>
>> On 8/25/17 13:18, Pramod Immaneni wrote:
>>
>>> Like I said, 1.x is not accurate, the project has already gone through
>>> 1.x,
>>> 2.x and it is at the version it is now. Resetting to 1.x or 1.0-SNAPSHOT
>>> is
>>> arbitrary. When the project was transitioned from non-apache open source
>>> to
>>> apache, a few years back, a case could have been made to reset the version
>>> as we were respawning life as a new project but not now. Even if we did
>>> reset the version at that point we cannot say what version we would be at
>>> now or say for sure we would be 1.0-SNAPSHOT now.
>>>
>>> When it comes to changing the name of the malhar project, there is a
>>> cost, malhar is a known entity with users and apart from the project
>>> dependency from code perspective, there is literature out there and not
>>> just on the apex website. This would be literature that our users have
>>> created describing malhar in the context of their applications or to
>>> promote apex within their organization, reviews from external entities and
>>> sites on apex project and other such references. Also, from the code
>>> perspective even though the specific code changes may look trivial that
>>> could end up being a development cycle for the users. With the version
>>> taken out of the equation because of the reasons described above, the cost
>>> is not justifiable.
>>>
>>> I don't know if I can explain the reasons above any other way. Either, you
>>> don't see my reasons as valid or we have a communication disconnect with
>>> your insistence that -1 is not valid. I clearly don't see a consensus
>>> here,
>>> there are others who are not in favor of changing the name and resetting
>>> the version as evidenced by the votes in the voting thread and we should
>>> end this discussion thread.
>>>
>>> Thanks
>>>
>>> On Fri, Aug 25, 2017 at 10:18 AM, Vlad Rozov <v....@gmail.com> wrote:
>>>
>>> I understand the preference and also explained why version and name change
>>>> is preferable in my view and what is broken with the current name and
>>>> version. The preference can and should be reflected in the vote, but at
>>>> the
>>>> end it's the community decision. I don't see why -1 would be a valid vote
>>>> at that point.
>>>>
>>>> Thank you,
>>>>
>>>> Vlad
>>>>
>>>>
>>>> On 8/25/17 09:57, Pramod Immaneni wrote:
>>>>
>>>> No, concerns for the changing the project name and version remain the
>>>>> same.
>>>>> I think the current version numbering train and name are fine and prefer
>>>>> we
>>>>> move forward and not backward by resetting things back to 1.x, which I
>>>>> believe is not accurate for the project. The name change is unnecessary,
>>>>> the name isn't broken that it needs to be fixed, it does not buy us much
>>>>> and causes unnecessary disruption for people who are already used to
>>>>> and malhar is already known out there. It is equivalent to asking for
>>>>> apex-core to be changed to apex-engine, engine is probably a better name
>>>>> but is it worth making the change, probably not, if it is not broke why
>>>>> fix
>>>>> it.
>>>>>
>>>>> Thanks
>>>>>
>>>>> On Fri, Aug 25, 2017 at 9:01 AM, Vlad Rozov <vr...@apache.org> wrote:
>>>>>
>>>>> How do we move from here? If all the concerns regarding version and
>>>>>
>>>>>> artifactId change are addressed we should move forward with the vote,
>>>>>> if
>>>>>> not, it will be good to raise them here rather than in the voting
>>>>>> thread.
>>>>>>
>>>>>> Thank you,
>>>>>>
>>>>>> Vlad
>>>>>>
>>>>>>
>>>>>> On 8/24/17 10:26, Thomas Weise wrote:
>>>>>>
>>>>>> On Thu, Aug 24, 2017 at 9:42 AM, Amol Kekre <am...@datatorrent.com>
>>>>>>
>>>>>>> wrote:
>>>>>>>
>>>>>>> In terms of rebasing versions, there is no urgency in mimic-ing some
>>>>>>> of
>>>>>>>
>>>>>>> the
>>>>>>>> other projects. Apex has already be been versioned.
>>>>>>>>
>>>>>>>> There is an expectation users have for a version number, which is
>>>>>>>>
>>>>>>> different
>>>>>>> for 3.x or 1.x or 0.x. Apex library maturity is nowhere near 3.x. That
>>>>>>> was
>>>>>>> already discussed.
>>>>>>>
>>>>>>> What functional gain do
>>>>>>>
>>>>>>> we have by changing versions, names? Functionality wise Apex users do
>>>>>>>
>>>>>>>> not
>>>>>>>> gain anything. With regards to bumping to 4.X, we should wait for a
>>>>>>>> proposal/plan for a new functional api.
>>>>>>>>
>>>>>>>> Addition of such API does not require major version change. New API
>>>>>>>> have
>>>>>>>>
>>>>>>>> been added and no major version change was done. Major version
>>>>>>> change is
>>>>>>> for backward incompatible changes.
>>>>>>>
>>>>>>> Examples:
>>>>>>> - rename packages
>>>>>>> - remove deprecated code
>>>>>>> - relocate operators that were not designed for production use
>>>>>>> - change to functionality of operators
>>>>>>>
>>>>>>> There is an illusion of backward compatibility (which does not exist
>>>>>>> today). That cannot be used as justification to not make changes.
>>>>>>>
>>>>>>>
>>>>>>> On Wed, Aug 23, 2017 at 10:26 AM, Vlad Rozov <vr...@apache.org>
>>>>>>> wrote:
>>>>>>>
>>>>>>> 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 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.
>>>>>>>>>>
>>>>>>>>>> Changing the name is as disruptive to users as changing minor/patch
>>>>>>>>>>
>>>>>>>>>> version. I don't see a big difference in changing one line in
>>>>>>>>> pom.xml
>>>>>>>>> (version) vs changing 2 lines (version and artifact). There is a
>>>>>>>>> bigger
>>>>>>>>> change/disruption that does IMO require major version change and
>>>>>>>>> renaming
>>>>>>>>> project to use the single brand (Apache Apex) at the same time is
>>>>>>>>> beneficial both to the project and users. Changing package and major
>>>>>>>>> version will impact documentation in much bigger way compared to
>>>>>>>>> changing
>>>>>>>>> artifactId.
>>>>>>>>>
>>>>>>>>> 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.
>>>>>>>>>
>>>>>>>>> There are many Apache projects that were around much longer than
>>>>>>>>>> malhar
>>>>>>>>>>
>>>>>>>>>> and have not yet reached 3.x version even though they are also
>>>>>>>>> used in
>>>>>>>>> production and are considered more stable. Number of evolving
>>>>>>>>> packages
>>>>>>>>>
>>>>>>>>> and
>>>>>>>>>
>>>>>>>> interfaces in malhar do not qualify it for 3.x or 4.x. IMO, version
>>>>>>>>
>>>>>>>>> must
>>>>>>>>>
>>>>>>>>> be
>>>>>>>>>
>>>>>>>> driven by the engineering/community, not by the marketing.
>>>>>>>>
>>>>>>>>> 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 don't think it is as drastic as it looks to be. It was done in a
>>>>>>>>>> past
>>>>>>>>>>
>>>>>>>>>> and is supported by all tools involved.
>>>>>>>>> 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.
>>>>>>>>>
>>>>>>>>> It will be good to provide details why is it "a big deal". Why
>>>>>>>>>> changing
>>>>>>>>>>
>>>>>>>>>> groupId was not a big deal and changing artifactId is a big deal?
>>>>>>>>> I completely agree with the increasing adoption, but it comes from
>>>>>>>>> the
>>>>>>>>> quality, not from the quantity and whether version is 1.x, 3.x or
>>>>>>>>> 4.x
>>>>>>>>>
>>>>>>>>> does
>>>>>>>>>
>>>>>>>> not change the quality of the library.
>>>>>>>>
>>>>>>>>> Thanks
>>>>>>>>>
>>>>>>>>> On Wed, Aug 23, 2017 at 8:09 AM Vlad Rozov <vr...@apache.org>
>>>>>>>>>> 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 <
>>>>>>>>>>
>>>>>>>>>>> justin@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
>>>>>>>>>>>>>
>>>>>>>>>>>>> Thank you,
>>>>>>>>>>>>>
>>>>>>>>>>>>> Vlad
>>>>>>>>>>> Thank you,
>>>>>>>>>>>
>>>>>>>>>>> Vlad
>>>>>>>>> Thank you,
>>>>>>>>>
>>>>>>>> Vlad
>>>>>>
>>>>>>
>> Thank you,
>>
>> Vlad
>>

Re: [DISCUSS] changing project name to apex-library

[Pramod Immaneni <pr...@datatorrent.com>]

On Sun, Aug 27, 2017 at 1:41 PM, Vlad Rozov <vr...@apache.org> wrote:

> 1.x may not be accurate, but 4.x (as well as 3.x, 2.x or 0.x) may not be
> accurate either. I don't see why 4.x is more accurate than 1.x. In any case
> this is personal preference and there is no *technical* justification not
> to go with 1.x once the artifactId is also changed.
>

4.x would be much better justified than 1.x because we are right now on 3.8
dev, thinking about making incompatible changes and combined with the fact
that we haven't been on 3.x only for a short period, logic would dictate
going to the next major version.


>
> -1 in a discussion thread is different from -1 in the voting thread. In a
> discussion thread it means "I strongly prefer/recommend that the community
> does not go that way". In the voting thread it means "I request that the
> changes are not implemented" (veto). For the veto to be valid, there must
> be *technical* reason not to move forward. In this particular case I would
> consider "maven does not support artifactId change" as a valid technical
> reason for -1.


By that logic there is no techical issue with renaming apex-core or
apex-malhar to apex-<anything> because almost anything will technically
work with maven and other tools. That being the only criteria doesn't make
sense and is not the case. One of the mentors noted the same in one of the
threads. There is no agreement that the project name should be changed and
so with justifiable reasons.

> A fact that somebody refers to a project as Malhar instead of Apache Apex
> is not a valid technical justification. Up to this point no valid technical
> justification was provided to stop artifactId and version change. I don't
> take "cost" as a valid technical justification either. There was a large
> cost to enforce checkstyle, but benefits from implementing checkstyle were
> definitely worth the cost.
>

That is a incorrect analogy, checkstyle was internal. It did not impact
users. What you are asking for, may not impact devs who are developing apex
as much but it impacts users and hence has "cost" that I detailed in my
earlier email and if it wasn't clear from my earlier emails is not good for
the continued adoption of the project. Regarding the technical
justification see my comment above.

Thanks

>
> Thank you,
>
> Vlad
>
> On 8/25/17 13:18, Pramod Immaneni wrote:
>
>> Like I said, 1.x is not accurate, the project has already gone through
>> 1.x,
>> 2.x and it is at the version it is now. Resetting to 1.x or 1.0-SNAPSHOT
>> is
>> arbitrary. When the project was transitioned from non-apache open source
>> to
>> apache, a few years back, a case could have been made to reset the version
>> as we were respawning life as a new project but not now. Even if we did
>> reset the version at that point we cannot say what version we would be at
>> now or say for sure we would be 1.0-SNAPSHOT now.
>>
>> When it comes to changing the name of the malhar project, there is a
>> cost, malhar is a known entity with users and apart from the project
>> dependency from code perspective, there is literature out there and not
>> just on the apex website. This would be literature that our users have
>> created describing malhar in the context of their applications or to
>> promote apex within their organization, reviews from external entities and
>> sites on apex project and other such references. Also, from the code
>> perspective even though the specific code changes may look trivial that
>> could end up being a development cycle for the users. With the version
>> taken out of the equation because of the reasons described above, the cost
>> is not justifiable.
>>
>> I don't know if I can explain the reasons above any other way. Either, you
>> don't see my reasons as valid or we have a communication disconnect with
>> your insistence that -1 is not valid. I clearly don't see a consensus
>> here,
>> there are others who are not in favor of changing the name and resetting
>> the version as evidenced by the votes in the voting thread and we should
>> end this discussion thread.
>>
>> Thanks
>>
>> On Fri, Aug 25, 2017 at 10:18 AM, Vlad Rozov <v....@gmail.com> wrote:
>>
>> I understand the preference and also explained why version and name change
>>> is preferable in my view and what is broken with the current name and
>>> version. The preference can and should be reflected in the vote, but at
>>> the
>>> end it's the community decision. I don't see why -1 would be a valid vote
>>> at that point.
>>>
>>> Thank you,
>>>
>>> Vlad
>>>
>>>
>>> On 8/25/17 09:57, Pramod Immaneni wrote:
>>>
>>> No, concerns for the changing the project name and version remain the
>>>> same.
>>>> I think the current version numbering train and name are fine and prefer
>>>> we
>>>> move forward and not backward by resetting things back to 1.x, which I
>>>> believe is not accurate for the project. The name change is unnecessary,
>>>> the name isn't broken that it needs to be fixed, it does not buy us much
>>>> and causes unnecessary disruption for people who are already used to
>>>> and malhar is already known out there. It is equivalent to asking for
>>>> apex-core to be changed to apex-engine, engine is probably a better name
>>>> but is it worth making the change, probably not, if it is not broke why
>>>> fix
>>>> it.
>>>>
>>>> Thanks
>>>>
>>>> On Fri, Aug 25, 2017 at 9:01 AM, Vlad Rozov <vr...@apache.org> wrote:
>>>>
>>>> How do we move from here? If all the concerns regarding version and
>>>>
>>>>> artifactId change are addressed we should move forward with the vote,
>>>>> if
>>>>> not, it will be good to raise them here rather than in the voting
>>>>> thread.
>>>>>
>>>>> Thank you,
>>>>>
>>>>> Vlad
>>>>>
>>>>>
>>>>> On 8/24/17 10:26, Thomas Weise wrote:
>>>>>
>>>>> On Thu, Aug 24, 2017 at 9:42 AM, Amol Kekre <am...@datatorrent.com>
>>>>>
>>>>>> wrote:
>>>>>>
>>>>>> In terms of rebasing versions, there is no urgency in mimic-ing some
>>>>>> of
>>>>>>
>>>>>> the
>>>>>>> other projects. Apex has already be been versioned.
>>>>>>>
>>>>>>> There is an expectation users have for a version number, which is
>>>>>>>
>>>>>> different
>>>>>> for 3.x or 1.x or 0.x. Apex library maturity is nowhere near 3.x. That
>>>>>> was
>>>>>> already discussed.
>>>>>>
>>>>>> What functional gain do
>>>>>>
>>>>>> we have by changing versions, names? Functionality wise Apex users do
>>>>>>
>>>>>>> not
>>>>>>> gain anything. With regards to bumping to 4.X, we should wait for a
>>>>>>> proposal/plan for a new functional api.
>>>>>>>
>>>>>>> Addition of such API does not require major version change. New API
>>>>>>> have
>>>>>>>
>>>>>>> been added and no major version change was done. Major version
>>>>>> change is
>>>>>> for backward incompatible changes.
>>>>>>
>>>>>> Examples:
>>>>>> - rename packages
>>>>>> - remove deprecated code
>>>>>> - relocate operators that were not designed for production use
>>>>>> - change to functionality of operators
>>>>>>
>>>>>> There is an illusion of backward compatibility (which does not exist
>>>>>> today). That cannot be used as justification to not make changes.
>>>>>>
>>>>>>
>>>>>> On Wed, Aug 23, 2017 at 10:26 AM, Vlad Rozov <vr...@apache.org>
>>>>>> wrote:
>>>>>>
>>>>>> 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 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.
>>>>>>>>>
>>>>>>>>> Changing the name is as disruptive to users as changing minor/patch
>>>>>>>>>
>>>>>>>>> version. I don't see a big difference in changing one line in
>>>>>>>> pom.xml
>>>>>>>> (version) vs changing 2 lines (version and artifact). There is a
>>>>>>>> bigger
>>>>>>>> change/disruption that does IMO require major version change and
>>>>>>>> renaming
>>>>>>>> project to use the single brand (Apache Apex) at the same time is
>>>>>>>> beneficial both to the project and users. Changing package and major
>>>>>>>> version will impact documentation in much bigger way compared to
>>>>>>>> changing
>>>>>>>> artifactId.
>>>>>>>>
>>>>>>>> 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.
>>>>>>>>
>>>>>>>> There are many Apache projects that were around much longer than
>>>>>>>>> malhar
>>>>>>>>>
>>>>>>>>> and have not yet reached 3.x version even though they are also
>>>>>>>> used in
>>>>>>>> production and are considered more stable. Number of evolving
>>>>>>>> packages
>>>>>>>>
>>>>>>>> and
>>>>>>>>
>>>>>>> interfaces in malhar do not qualify it for 3.x or 4.x. IMO, version
>>>>>>>
>>>>>>>> must
>>>>>>>>
>>>>>>>> be
>>>>>>>>
>>>>>>> driven by the engineering/community, not by the marketing.
>>>>>>>
>>>>>>>> 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 don't think it is as drastic as it looks to be. It was done in a
>>>>>>>>> past
>>>>>>>>>
>>>>>>>>> and is supported by all tools involved.
>>>>>>>>
>>>>>>>> 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.
>>>>>>>>
>>>>>>>> It will be good to provide details why is it "a big deal". Why
>>>>>>>>> changing
>>>>>>>>>
>>>>>>>>> groupId was not a big deal and changing artifactId is a big deal?
>>>>>>>>
>>>>>>>> I completely agree with the increasing adoption, but it comes from
>>>>>>>> the
>>>>>>>> quality, not from the quantity and whether version is 1.x, 3.x or
>>>>>>>> 4.x
>>>>>>>>
>>>>>>>> does
>>>>>>>>
>>>>>>> not change the quality of the library.
>>>>>>>
>>>>>>>> Thanks
>>>>>>>>
>>>>>>>> On Wed, Aug 23, 2017 at 8:09 AM Vlad Rozov <vr...@apache.org>
>>>>>>>>> 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 <
>>>>>>>>>
>>>>>>>>>> justin@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
>>>>>>>>>>>>
>>>>>>>>>>>> Thank you,
>>>>>>>>>>>>
>>>>>>>>>>>> Vlad
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Thank you,
>>>>>>>>>>
>>>>>>>>>> Vlad
>>>>>>>>>
>>>>>>>>
>>>>>>>> Thank you,
>>>>>>>>
>>>>>>> Vlad
>>>>>
>>>>>
>>>>>
>
> Thank you,
>
> Vlad
>

Re: [DISCUSS] changing project name to apex-library

[Vlad Rozov <vr...@apache.org>]

1.x may not be accurate, but 4.x (as well as 3.x, 2.x or 0.x) may not be 
accurate either. I don't see why 4.x is more accurate than 1.x. In any 
case this is personal preference and there is no *technical* 
justification not to go with 1.x once the artifactId is also changed.

-1 in a discussion thread is different from -1 in the voting thread. In 
a discussion thread it means "I strongly prefer/recommend that the 
community does not go that way". In the voting thread it means "I 
request that the changes are not implemented" (veto). For the veto to be 
valid, there must be *technical* reason not to move forward. In this 
particular case I would consider "maven does not support artifactId 
change" as a valid technical reason for -1. A fact that somebody refers 
to a project as Malhar instead of Apache Apex is not a valid technical 
justification. Up to this point no valid technical justification was 
provided to stop artifactId and version change. I don't take "cost" as a 
valid technical justification either. There was a large cost to enforce 
checkstyle, but benefits from implementing checkstyle were definitely 
worth the cost.

Thank you,

Vlad

On 8/25/17 13:18, Pramod Immaneni wrote:
> Like I said, 1.x is not accurate, the project has already gone through 1.x,
> 2.x and it is at the version it is now. Resetting to 1.x or 1.0-SNAPSHOT is
> arbitrary. When the project was transitioned from non-apache open source to
> apache, a few years back, a case could have been made to reset the version
> as we were respawning life as a new project but not now. Even if we did
> reset the version at that point we cannot say what version we would be at
> now or say for sure we would be 1.0-SNAPSHOT now.
>
> When it comes to changing the name of the malhar project, there is a
> cost, malhar is a known entity with users and apart from the project
> dependency from code perspective, there is literature out there and not
> just on the apex website. This would be literature that our users have
> created describing malhar in the context of their applications or to
> promote apex within their organization, reviews from external entities and
> sites on apex project and other such references. Also, from the code
> perspective even though the specific code changes may look trivial that
> could end up being a development cycle for the users. With the version
> taken out of the equation because of the reasons described above, the cost
> is not justifiable.
>
> I don't know if I can explain the reasons above any other way. Either, you
> don't see my reasons as valid or we have a communication disconnect with
> your insistence that -1 is not valid. I clearly don't see a consensus here,
> there are others who are not in favor of changing the name and resetting
> the version as evidenced by the votes in the voting thread and we should
> end this discussion thread.
>
> Thanks
>
> On Fri, Aug 25, 2017 at 10:18 AM, Vlad Rozov <v....@gmail.com> wrote:
>
>> I understand the preference and also explained why version and name change
>> is preferable in my view and what is broken with the current name and
>> version. The preference can and should be reflected in the vote, but at the
>> end it's the community decision. I don't see why -1 would be a valid vote
>> at that point.
>>
>> Thank you,
>>
>> Vlad
>>
>>
>> On 8/25/17 09:57, Pramod Immaneni wrote:
>>
>>> No, concerns for the changing the project name and version remain the
>>> same.
>>> I think the current version numbering train and name are fine and prefer
>>> we
>>> move forward and not backward by resetting things back to 1.x, which I
>>> believe is not accurate for the project. The name change is unnecessary,
>>> the name isn't broken that it needs to be fixed, it does not buy us much
>>> and causes unnecessary disruption for people who are already used to
>>> and malhar is already known out there. It is equivalent to asking for
>>> apex-core to be changed to apex-engine, engine is probably a better name
>>> but is it worth making the change, probably not, if it is not broke why
>>> fix
>>> it.
>>>
>>> Thanks
>>>
>>> On Fri, Aug 25, 2017 at 9:01 AM, Vlad Rozov <vr...@apache.org> wrote:
>>>
>>> How do we move from here? If all the concerns regarding version and
>>>> artifactId change are addressed we should move forward with the vote, if
>>>> not, it will be good to raise them here rather than in the voting thread.
>>>>
>>>> Thank you,
>>>>
>>>> Vlad
>>>>
>>>>
>>>> On 8/24/17 10:26, Thomas Weise wrote:
>>>>
>>>> On Thu, Aug 24, 2017 at 9:42 AM, Amol Kekre <am...@datatorrent.com>
>>>>> wrote:
>>>>>
>>>>> In terms of rebasing versions, there is no urgency in mimic-ing some of
>>>>>
>>>>>> the
>>>>>> other projects. Apex has already be been versioned.
>>>>>>
>>>>>> There is an expectation users have for a version number, which is
>>>>> different
>>>>> for 3.x or 1.x or 0.x. Apex library maturity is nowhere near 3.x. That
>>>>> was
>>>>> already discussed.
>>>>>
>>>>> What functional gain do
>>>>>
>>>>> we have by changing versions, names? Functionality wise Apex users do
>>>>>> not
>>>>>> gain anything. With regards to bumping to 4.X, we should wait for a
>>>>>> proposal/plan for a new functional api.
>>>>>>
>>>>>> Addition of such API does not require major version change. New API
>>>>>> have
>>>>>>
>>>>> been added and no major version change was done. Major version change is
>>>>> for backward incompatible changes.
>>>>>
>>>>> Examples:
>>>>> - rename packages
>>>>> - remove deprecated code
>>>>> - relocate operators that were not designed for production use
>>>>> - change to functionality of operators
>>>>>
>>>>> There is an illusion of backward compatibility (which does not exist
>>>>> today). That cannot be used as justification to not make changes.
>>>>>
>>>>>
>>>>> On Wed, Aug 23, 2017 at 10:26 AM, Vlad Rozov <vr...@apache.org> wrote:
>>>>>
>>>>>> 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 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.
>>>>>>>>
>>>>>>>> Changing the name is as disruptive to users as changing minor/patch
>>>>>>>>
>>>>>>> version. I don't see a big difference in changing one line in pom.xml
>>>>>>> (version) vs changing 2 lines (version and artifact). There is a
>>>>>>> bigger
>>>>>>> change/disruption that does IMO require major version change and
>>>>>>> renaming
>>>>>>> project to use the single brand (Apache Apex) at the same time is
>>>>>>> beneficial both to the project and users. Changing package and major
>>>>>>> version will impact documentation in much bigger way compared to
>>>>>>> changing
>>>>>>> artifactId.
>>>>>>>
>>>>>>> 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.
>>>>>>>
>>>>>>>> There are many Apache projects that were around much longer than
>>>>>>>> malhar
>>>>>>>>
>>>>>>> and have not yet reached 3.x version even though they are also used in
>>>>>>> production and are considered more stable. Number of evolving packages
>>>>>>>
>>>>>>> and
>>>>>> interfaces in malhar do not qualify it for 3.x or 4.x. IMO, version
>>>>>>> must
>>>>>>>
>>>>>>> be
>>>>>> driven by the engineering/community, not by the marketing.
>>>>>>> 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 don't think it is as drastic as it looks to be. It was done in a
>>>>>>>> past
>>>>>>>>
>>>>>>> and is supported by all tools involved.
>>>>>>>
>>>>>>> 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.
>>>>>>>
>>>>>>>> It will be good to provide details why is it "a big deal". Why
>>>>>>>> changing
>>>>>>>>
>>>>>>> groupId was not a big deal and changing artifactId is a big deal?
>>>>>>>
>>>>>>> I completely agree with the increasing adoption, but it comes from the
>>>>>>> quality, not from the quantity and whether version is 1.x, 3.x or 4.x
>>>>>>>
>>>>>>> does
>>>>>> not change the quality of the library.
>>>>>>> Thanks
>>>>>>>
>>>>>>>> On Wed, Aug 23, 2017 at 8:09 AM Vlad Rozov <vr...@apache.org>
>>>>>>>> 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 <
>>>>>>>>>> justin@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
>>>>>>>>>>>
>>>>>>>>>>> Thank you,
>>>>>>>>>>>
>>>>>>>>>> Vlad
>>>>>>>>>
>>>>>>>>> Thank you,
>>>>>>>>>
>>>>>>>> Vlad
>>>>>>>
>>>>>>> Thank you,
>>>> Vlad
>>>>
>>>>


Thank you,

Vlad

Re: [DISCUSS] changing project name to apex-library

[Pramod Immaneni <pr...@datatorrent.com>]

Like I said, 1.x is not accurate, the project has already gone through 1.x,
2.x and it is at the version it is now. Resetting to 1.x or 1.0-SNAPSHOT is
arbitrary. When the project was transitioned from non-apache open source to
apache, a few years back, a case could have been made to reset the version
as we were respawning life as a new project but not now. Even if we did
reset the version at that point we cannot say what version we would be at
now or say for sure we would be 1.0-SNAPSHOT now.

When it comes to changing the name of the malhar project, there is a
cost, malhar is a known entity with users and apart from the project
dependency from code perspective, there is literature out there and not
just on the apex website. This would be literature that our users have
created describing malhar in the context of their applications or to
promote apex within their organization, reviews from external entities and
sites on apex project and other such references. Also, from the code
perspective even though the specific code changes may look trivial that
could end up being a development cycle for the users. With the version
taken out of the equation because of the reasons described above, the cost
is not justifiable.

I don't know if I can explain the reasons above any other way. Either, you
don't see my reasons as valid or we have a communication disconnect with
your insistence that -1 is not valid. I clearly don't see a consensus here,
there are others who are not in favor of changing the name and resetting
the version as evidenced by the votes in the voting thread and we should
end this discussion thread.

Thanks

On Fri, Aug 25, 2017 at 10:18 AM, Vlad Rozov <v....@gmail.com> wrote:

> I understand the preference and also explained why version and name change
> is preferable in my view and what is broken with the current name and
> version. The preference can and should be reflected in the vote, but at the
> end it's the community decision. I don't see why -1 would be a valid vote
> at that point.
>
> Thank you,
>
> Vlad
>
>
> On 8/25/17 09:57, Pramod Immaneni wrote:
>
>> No, concerns for the changing the project name and version remain the
>> same.
>> I think the current version numbering train and name are fine and prefer
>> we
>> move forward and not backward by resetting things back to 1.x, which I
>> believe is not accurate for the project. The name change is unnecessary,
>> the name isn't broken that it needs to be fixed, it does not buy us much
>> and causes unnecessary disruption for people who are already used to
>> and malhar is already known out there. It is equivalent to asking for
>> apex-core to be changed to apex-engine, engine is probably a better name
>> but is it worth making the change, probably not, if it is not broke why
>> fix
>> it.
>>
>> Thanks
>>
>> On Fri, Aug 25, 2017 at 9:01 AM, Vlad Rozov <vr...@apache.org> wrote:
>>
>> How do we move from here? If all the concerns regarding version and
>>> artifactId change are addressed we should move forward with the vote, if
>>> not, it will be good to raise them here rather than in the voting thread.
>>>
>>> Thank you,
>>>
>>> Vlad
>>>
>>>
>>> On 8/24/17 10:26, Thomas Weise wrote:
>>>
>>> On Thu, Aug 24, 2017 at 9:42 AM, Amol Kekre <am...@datatorrent.com>
>>>> wrote:
>>>>
>>>> In terms of rebasing versions, there is no urgency in mimic-ing some of
>>>>
>>>>> the
>>>>> other projects. Apex has already be been versioned.
>>>>>
>>>>> There is an expectation users have for a version number, which is
>>>> different
>>>> for 3.x or 1.x or 0.x. Apex library maturity is nowhere near 3.x. That
>>>> was
>>>> already discussed.
>>>>
>>>> What functional gain do
>>>>
>>>> we have by changing versions, names? Functionality wise Apex users do
>>>>> not
>>>>> gain anything. With regards to bumping to 4.X, we should wait for a
>>>>> proposal/plan for a new functional api.
>>>>>
>>>>> Addition of such API does not require major version change. New API
>>>>> have
>>>>>
>>>> been added and no major version change was done. Major version change is
>>>> for backward incompatible changes.
>>>>
>>>> Examples:
>>>> - rename packages
>>>> - remove deprecated code
>>>> - relocate operators that were not designed for production use
>>>> - change to functionality of operators
>>>>
>>>> There is an illusion of backward compatibility (which does not exist
>>>> today). That cannot be used as justification to not make changes.
>>>>
>>>>
>>>> On Wed, Aug 23, 2017 at 10:26 AM, Vlad Rozov <vr...@apache.org> wrote:
>>>>
>>>>> 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 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.
>>>>>>>
>>>>>>> Changing the name is as disruptive to users as changing minor/patch
>>>>>>>
>>>>>> version. I don't see a big difference in changing one line in pom.xml
>>>>>> (version) vs changing 2 lines (version and artifact). There is a
>>>>>> bigger
>>>>>> change/disruption that does IMO require major version change and
>>>>>> renaming
>>>>>> project to use the single brand (Apache Apex) at the same time is
>>>>>> beneficial both to the project and users. Changing package and major
>>>>>> version will impact documentation in much bigger way compared to
>>>>>> changing
>>>>>> artifactId.
>>>>>>
>>>>>> 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.
>>>>>>
>>>>>>> There are many Apache projects that were around much longer than
>>>>>>> malhar
>>>>>>>
>>>>>> and have not yet reached 3.x version even though they are also used in
>>>>>> production and are considered more stable. Number of evolving packages
>>>>>>
>>>>>> and
>>>>>
>>>>> interfaces in malhar do not qualify it for 3.x or 4.x. IMO, version
>>>>>> must
>>>>>>
>>>>>> be
>>>>>
>>>>> driven by the engineering/community, not by the marketing.
>>>>>>
>>>>>> 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 don't think it is as drastic as it looks to be. It was done in a
>>>>>>> past
>>>>>>>
>>>>>> and is supported by all tools involved.
>>>>>>
>>>>>> 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.
>>>>>>
>>>>>>> It will be good to provide details why is it "a big deal". Why
>>>>>>> changing
>>>>>>>
>>>>>> groupId was not a big deal and changing artifactId is a big deal?
>>>>>>
>>>>>> I completely agree with the increasing adoption, but it comes from the
>>>>>> quality, not from the quantity and whether version is 1.x, 3.x or 4.x
>>>>>>
>>>>>> does
>>>>>
>>>>> not change the quality of the library.
>>>>>>
>>>>>> Thanks
>>>>>>
>>>>>>>
>>>>>>> On Wed, Aug 23, 2017 at 8:09 AM Vlad Rozov <vr...@apache.org>
>>>>>>> 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 <
>>>>>>>>> justin@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
>>>>>>>>>>
>>>>>>>>>> Thank you,
>>>>>>>>>>
>>>>>>>>> Vlad
>>>>>>>>
>>>>>>>>
>>>>>>>> Thank you,
>>>>>>>>
>>>>>>> Vlad
>>>>>>
>>>>>>
>>>>>> Thank you,
>>>
>>> Vlad
>>>
>>>
>

Re: [DISCUSS] changing project name to apex-library

[Vlad Rozov <v....@gmail.com>]

I understand the preference and also explained why version and name 
change is preferable in my view and what is broken with the current name 
and version. The preference can and should be reflected in the vote, but 
at the end it's the community decision. I don't see why -1 would be a 
valid vote at that point.

Thank you,

Vlad

On 8/25/17 09:57, Pramod Immaneni wrote:
> No, concerns for the changing the project name and version remain the same.
> I think the current version numbering train and name are fine and prefer we
> move forward and not backward by resetting things back to 1.x, which I
> believe is not accurate for the project. The name change is unnecessary,
> the name isn't broken that it needs to be fixed, it does not buy us much
> and causes unnecessary disruption for people who are already used to
> and malhar is already known out there. It is equivalent to asking for
> apex-core to be changed to apex-engine, engine is probably a better name
> but is it worth making the change, probably not, if it is not broke why fix
> it.
>
> Thanks
>
> On Fri, Aug 25, 2017 at 9:01 AM, Vlad Rozov <vr...@apache.org> wrote:
>
>> How do we move from here? If all the concerns regarding version and
>> artifactId change are addressed we should move forward with the vote, if
>> not, it will be good to raise them here rather than in the voting thread.
>>
>> Thank you,
>>
>> Vlad
>>
>>
>> On 8/24/17 10:26, Thomas Weise wrote:
>>
>>> On Thu, Aug 24, 2017 at 9:42 AM, Amol Kekre <am...@datatorrent.com> wrote:
>>>
>>> In terms of rebasing versions, there is no urgency in mimic-ing some of
>>>> the
>>>> other projects. Apex has already be been versioned.
>>>>
>>> There is an expectation users have for a version number, which is
>>> different
>>> for 3.x or 1.x or 0.x. Apex library maturity is nowhere near 3.x. That was
>>> already discussed.
>>>
>>> What functional gain do
>>>
>>>> we have by changing versions, names? Functionality wise Apex users do not
>>>> gain anything. With regards to bumping to 4.X, we should wait for a
>>>> proposal/plan for a new functional api.
>>>>
>>>> Addition of such API does not require major version change. New API have
>>> been added and no major version change was done. Major version change is
>>> for backward incompatible changes.
>>>
>>> Examples:
>>> - rename packages
>>> - remove deprecated code
>>> - relocate operators that were not designed for production use
>>> - change to functionality of operators
>>>
>>> There is an illusion of backward compatibility (which does not exist
>>> today). That cannot be used as justification to not make changes.
>>>
>>>
>>> On Wed, Aug 23, 2017 at 10:26 AM, Vlad Rozov <vr...@apache.org> wrote:
>>>> 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 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.
>>>>>>
>>>>>> Changing the name is as disruptive to users as changing minor/patch
>>>>> version. I don't see a big difference in changing one line in pom.xml
>>>>> (version) vs changing 2 lines (version and artifact). There is a bigger
>>>>> change/disruption that does IMO require major version change and
>>>>> renaming
>>>>> project to use the single brand (Apache Apex) at the same time is
>>>>> beneficial both to the project and users. Changing package and major
>>>>> version will impact documentation in much bigger way compared to
>>>>> changing
>>>>> artifactId.
>>>>>
>>>>> 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.
>>>>>> There are many Apache projects that were around much longer than malhar
>>>>> and have not yet reached 3.x version even though they are also used in
>>>>> production and are considered more stable. Number of evolving packages
>>>>>
>>>> and
>>>>
>>>>> interfaces in malhar do not qualify it for 3.x or 4.x. IMO, version must
>>>>>
>>>> be
>>>>
>>>>> driven by the engineering/community, not by the marketing.
>>>>>
>>>>> 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 don't think it is as drastic as it looks to be. It was done in a past
>>>>> and is supported by all tools involved.
>>>>>
>>>>> 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.
>>>>>> It will be good to provide details why is it "a big deal". Why changing
>>>>> groupId was not a big deal and changing artifactId is a big deal?
>>>>>
>>>>> I completely agree with the increasing adoption, but it comes from the
>>>>> quality, not from the quantity and whether version is 1.x, 3.x or 4.x
>>>>>
>>>> does
>>>>
>>>>> not change the quality of the library.
>>>>>
>>>>> Thanks
>>>>>>
>>>>>> On Wed, Aug 23, 2017 at 8:09 AM Vlad Rozov <vr...@apache.org> 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 <
>>>>>>>> justin@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
>>>>>>>>>
>>>>>>>>> Thank you,
>>>>>>> Vlad
>>>>>>>
>>>>>>>
>>>>>>> Thank you,
>>>>> Vlad
>>>>>
>>>>>
>> Thank you,
>>
>> Vlad
>>

Re: [DISCUSS] changing project name to apex-library

[Pramod Immaneni <pr...@datatorrent.com>]

No, concerns for the changing the project name and version remain the same.
I think the current version numbering train and name are fine and prefer we
move forward and not backward by resetting things back to 1.x, which I
believe is not accurate for the project. The name change is unnecessary,
the name isn't broken that it needs to be fixed, it does not buy us much
and causes unnecessary disruption for people who are already used to
and malhar is already known out there. It is equivalent to asking for
apex-core to be changed to apex-engine, engine is probably a better name
but is it worth making the change, probably not, if it is not broke why fix
it.

Thanks

On Fri, Aug 25, 2017 at 9:01 AM, Vlad Rozov <vr...@apache.org> wrote:

> How do we move from here? If all the concerns regarding version and
> artifactId change are addressed we should move forward with the vote, if
> not, it will be good to raise them here rather than in the voting thread.
>
> Thank you,
>
> Vlad
>
>
> On 8/24/17 10:26, Thomas Weise wrote:
>
>> On Thu, Aug 24, 2017 at 9:42 AM, Amol Kekre <am...@datatorrent.com> wrote:
>>
>> In terms of rebasing versions, there is no urgency in mimic-ing some of
>>> the
>>> other projects. Apex has already be been versioned.
>>>
>>
>> There is an expectation users have for a version number, which is
>> different
>> for 3.x or 1.x or 0.x. Apex library maturity is nowhere near 3.x. That was
>> already discussed.
>>
>> What functional gain do
>>
>>> we have by changing versions, names? Functionality wise Apex users do not
>>> gain anything. With regards to bumping to 4.X, we should wait for a
>>> proposal/plan for a new functional api.
>>>
>>> Addition of such API does not require major version change. New API have
>> been added and no major version change was done. Major version change is
>> for backward incompatible changes.
>>
>> Examples:
>> - rename packages
>> - remove deprecated code
>> - relocate operators that were not designed for production use
>> - change to functionality of operators
>>
>> There is an illusion of backward compatibility (which does not exist
>> today). That cannot be used as justification to not make changes.
>>
>>
>> On Wed, Aug 23, 2017 at 10:26 AM, Vlad Rozov <vr...@apache.org> wrote:
>>>
>>> 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 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.
>>>>>
>>>>> Changing the name is as disruptive to users as changing minor/patch
>>>> version. I don't see a big difference in changing one line in pom.xml
>>>> (version) vs changing 2 lines (version and artifact). There is a bigger
>>>> change/disruption that does IMO require major version change and
>>>> renaming
>>>> project to use the single brand (Apache Apex) at the same time is
>>>> beneficial both to the project and users. Changing package and major
>>>> version will impact documentation in much bigger way compared to
>>>> changing
>>>> artifactId.
>>>>
>>>> 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.
>>>>>
>>>>> There are many Apache projects that were around much longer than malhar
>>>> and have not yet reached 3.x version even though they are also used in
>>>> production and are considered more stable. Number of evolving packages
>>>>
>>> and
>>>
>>>> interfaces in malhar do not qualify it for 3.x or 4.x. IMO, version must
>>>>
>>> be
>>>
>>>> driven by the engineering/community, not by the marketing.
>>>>
>>>> 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 don't think it is as drastic as it looks to be. It was done in a past
>>>> and is supported by all tools involved.
>>>>
>>>> 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.
>>>>>
>>>>> It will be good to provide details why is it "a big deal". Why changing
>>>> groupId was not a big deal and changing artifactId is a big deal?
>>>>
>>>> I completely agree with the increasing adoption, but it comes from the
>>>> quality, not from the quantity and whether version is 1.x, 3.x or 4.x
>>>>
>>> does
>>>
>>>> not change the quality of the library.
>>>>
>>>> Thanks
>>>>>
>>>>>
>>>>> On Wed, Aug 23, 2017 at 8:09 AM Vlad Rozov <vr...@apache.org> 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 <
>>>>>>> justin@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
>>>>>>>>
>>>>>>>> Thank you,
>>>>>>
>>>>>> Vlad
>>>>>>
>>>>>>
>>>>>> Thank you,
>>>>
>>>> Vlad
>>>>
>>>>
>
> Thank you,
>
> Vlad
>

Re: [DISCUSS] changing project name to apex-library

[Vlad Rozov <vr...@apache.org>]

How do we move from here? If all the concerns regarding version and 
artifactId change are addressed we should move forward with the vote, if 
not, it will be good to raise them here rather than in the voting thread.

Thank you,

Vlad

On 8/24/17 10:26, Thomas Weise wrote:
> On Thu, Aug 24, 2017 at 9:42 AM, Amol Kekre <am...@datatorrent.com> wrote:
>
>> In terms of rebasing versions, there is no urgency in mimic-ing some of the
>> other projects. Apex has already be been versioned.
>
> There is an expectation users have for a version number, which is different
> for 3.x or 1.x or 0.x. Apex library maturity is nowhere near 3.x. That was
> already discussed.
>
> What functional gain do
>> we have by changing versions, names? Functionality wise Apex users do not
>> gain anything. With regards to bumping to 4.X, we should wait for a
>> proposal/plan for a new functional api.
>>
> Addition of such API does not require major version change. New API have
> been added and no major version change was done. Major version change is
> for backward incompatible changes.
>
> Examples:
> - rename packages
> - remove deprecated code
> - relocate operators that were not designed for production use
> - change to functionality of operators
>
> There is an illusion of backward compatibility (which does not exist
> today). That cannot be used as justification to not make changes.
>
>
>> On Wed, Aug 23, 2017 at 10:26 AM, Vlad Rozov <vr...@apache.org> wrote:
>>
>>> 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 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.
>>>>
>>> Changing the name is as disruptive to users as changing minor/patch
>>> version. I don't see a big difference in changing one line in pom.xml
>>> (version) vs changing 2 lines (version and artifact). There is a bigger
>>> change/disruption that does IMO require major version change and renaming
>>> project to use the single brand (Apache Apex) at the same time is
>>> beneficial both to the project and users. Changing package and major
>>> version will impact documentation in much bigger way compared to changing
>>> artifactId.
>>>
>>>> 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.
>>>>
>>> There are many Apache projects that were around much longer than malhar
>>> and have not yet reached 3.x version even though they are also used in
>>> production and are considered more stable. Number of evolving packages
>> and
>>> interfaces in malhar do not qualify it for 3.x or 4.x. IMO, version must
>> be
>>> driven by the engineering/community, not by the marketing.
>>>
>>>> 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 don't think it is as drastic as it looks to be. It was done in a past
>>> and is supported by all tools involved.
>>>
>>>> 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.
>>>>
>>> It will be good to provide details why is it "a big deal". Why changing
>>> groupId was not a big deal and changing artifactId is a big deal?
>>>
>>> I completely agree with the increasing adoption, but it comes from the
>>> quality, not from the quantity and whether version is 1.x, 3.x or 4.x
>> does
>>> not change the quality of the library.
>>>
>>>> Thanks
>>>>
>>>>
>>>> On Wed, Aug 23, 2017 at 8:09 AM Vlad Rozov <vr...@apache.org> 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 <
>>>>>> justin@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
>>>>>>>
>>>>> Thank you,
>>>>>
>>>>> Vlad
>>>>>
>>>>>
>>> Thank you,
>>>
>>> Vlad
>>>


Thank you,

Vlad

Re: [DISCUSS] changing project name to apex-library

[Thomas Weise <th...@apache.org>]

On Thu, Aug 24, 2017 at 9:42 AM, Amol Kekre <am...@datatorrent.com> wrote:

> In terms of rebasing versions, there is no urgency in mimic-ing some of the
> other projects. Apex has already be been versioned.


There is an expectation users have for a version number, which is different
for 3.x or 1.x or 0.x. Apex library maturity is nowhere near 3.x. That was
already discussed.

What functional gain do
> we have by changing versions, names? Functionality wise Apex users do not
> gain anything. With regards to bumping to 4.X, we should wait for a
> proposal/plan for a new functional api.
>

Addition of such API does not require major version change. New API have
been added and no major version change was done. Major version change is
for backward incompatible changes.

Examples:
- rename packages
- remove deprecated code
- relocate operators that were not designed for production use
- change to functionality of operators

There is an illusion of backward compatibility (which does not exist
today). That cannot be used as justification to not make changes.


> On Wed, Aug 23, 2017 at 10:26 AM, Vlad Rozov <vr...@apache.org> wrote:
>
> > 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 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.
> >>
> > Changing the name is as disruptive to users as changing minor/patch
> > version. I don't see a big difference in changing one line in pom.xml
> > (version) vs changing 2 lines (version and artifact). There is a bigger
> > change/disruption that does IMO require major version change and renaming
> > project to use the single brand (Apache Apex) at the same time is
> > beneficial both to the project and users. Changing package and major
> > version will impact documentation in much bigger way compared to changing
> > artifactId.
> >
> >>
> >> 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.
> >>
> > There are many Apache projects that were around much longer than malhar
> > and have not yet reached 3.x version even though they are also used in
> > production and are considered more stable. Number of evolving packages
> and
> > interfaces in malhar do not qualify it for 3.x or 4.x. IMO, version must
> be
> > driven by the engineering/community, not by the marketing.
> >
> >>
> >> 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 don't think it is as drastic as it looks to be. It was done in a past
> > and is supported by all tools involved.
> >
> >>
> >> 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.
> >>
> > It will be good to provide details why is it "a big deal". Why changing
> > groupId was not a big deal and changing artifactId is a big deal?
> >
> > I completely agree with the increasing adoption, but it comes from the
> > quality, not from the quantity and whether version is 1.x, 3.x or 4.x
> does
> > not change the quality of the library.
> >
> >>
> >> Thanks
> >>
> >>
> >> On Wed, Aug 23, 2017 at 8:09 AM Vlad Rozov <vr...@apache.org> 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 <
> >>>> justin@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
> >>>>>
> >>>>
> >>> Thank you,
> >>>
> >>> Vlad
> >>>
> >>>
> >
> > Thank you,
> >
> > Vlad
> >
>

Re: [DISCUSS] changing project name to apex-library

[Amol Kekre <am...@datatorrent.com>]

In terms of rebasing versions, there is no urgency in mimic-ing some of the
other projects. Apex has already be been versioned. What functional gain do
we have by changing versions, names? Functionality wise Apex users do not
gain anything. With regards to bumping to 4.X, we should wait for a
proposal/plan for a new functional api.

Thks,
Amol


E:amol@datatorrent.com | M: 510-449-2606 | Twitter: @*amolhkekre*

www.datatorrent.com


On Wed, Aug 23, 2017 at 10:26 AM, Vlad Rozov <vr...@apache.org> wrote:

> 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 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.
>>
> Changing the name is as disruptive to users as changing minor/patch
> version. I don't see a big difference in changing one line in pom.xml
> (version) vs changing 2 lines (version and artifact). There is a bigger
> change/disruption that does IMO require major version change and renaming
> project to use the single brand (Apache Apex) at the same time is
> beneficial both to the project and users. Changing package and major
> version will impact documentation in much bigger way compared to changing
> artifactId.
>
>>
>> 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.
>>
> There are many Apache projects that were around much longer than malhar
> and have not yet reached 3.x version even though they are also used in
> production and are considered more stable. Number of evolving packages and
> interfaces in malhar do not qualify it for 3.x or 4.x. IMO, version must be
> driven by the engineering/community, not by the marketing.
>
>>
>> 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 don't think it is as drastic as it looks to be. It was done in a past
> and is supported by all tools involved.
>
>>
>> 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.
>>
> It will be good to provide details why is it "a big deal". Why changing
> groupId was not a big deal and changing artifactId is a big deal?
>
> I completely agree with the increasing adoption, but it comes from the
> quality, not from the quantity and whether version is 1.x, 3.x or 4.x does
> not change the quality of the library.
>
>>
>> Thanks
>>
>>
>> On Wed, Aug 23, 2017 at 8:09 AM Vlad Rozov <vr...@apache.org> 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 <
>>>> justin@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
>>>>>
>>>>
>>> Thank you,
>>>
>>> Vlad
>>>
>>>
>
> Thank you,
>
> Vlad
>