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

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

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

Versioning and parallel release lines exist for a reason. Nothing needs to
be reinvented, everything that is needed to not disrupt existing users
while allowing for changes that evolve a product already exists.

A number of folks don't wear the project hat, don't contribute in a
constructive manner and are otherwise not actively visible in the project.
Do they participate in this discussion out of their own interest or because
they are paid to do so? That combined with a look at the contributor stats
should provide a fairly good orientation.

This discussion here is about making changes and evolve the project, not to
organize a DataTorrent & friends blockade. Put your own effort, research,
follow a discussion thread, present your own opinion. Separately, it will
be necessary to take up the topic of project independence at the PMC level.

Thomas


On Fri, Sep 1, 2017 at 3:14 PM, Sandeep Deshmukh <sandeep.deshmukh@gmail.com
> wrote:

> I totally agree with Sandesh. Things are being pushed when there is clear
> disagreement. If Apex has to grow the community, it can't grow using divide
> and conquer method.
>
> On Fri, Sep 1, 2017 at 10:45 PM, Sandesh Hegde <sa...@datatorrent.com>
> wrote:
>
> > Using all the technicalities and loop holes, we can declare many votes
> > invalid. What purpose does it solve? This thread is dividing the
> community,
> > instead of recognizing the difference if we move forward with this, there
> > is a chance that Apex will alienate many contributors. What's the end
> game
> > here? At what cost?
> >
> > On Fri, Sep 1, 2017 at 9:31 AM Thomas Weise <th...@apache.org> wrote:
> >
> > > Yes, you would need a separate discussion/vote on changes not being
> > > reflected in master that you make to a branch (current procedure).
> > >
> > > Regarding procedural vote, the decision to start development towards
> new
> > > major release is a longer term decision, not just code change.
> > >
> > > https://www.apache.org/foundation/glossary.html#MajorityApproval
> > >
> > > "Refers to a vote (sense 1) which has completed with at least three
> > binding
> > > +1 votes and more +1 votes than -1 votes. ( I.e. , a simple majority
> > with a
> > > minimum quorum of three positive votes.) Note that in votes requiring
> > > majority approval a -1 vote is simply a vote against, not a veto.
> Compare
> > > Consensus Approval. See also the description of the voting process."
> > >
> > >
> > > For code modifications the rules are different, -1 is a veto that needs
> > to
> > > have a valid technical reason why the change cannot be made. Otherwise
> it
> > > is void. None of the -1s in the vote result provide such justification.
> > >
> > > Thanks,
> > > Thomas
> > >
> > >
> > >
> > > On Thu, Aug 31, 2017 at 10:06 PM, Pramod Immaneni <
> > pramod@datatorrent.com>
> > > wrote:
> > >
> > > > Thomas,
> > > >
> > > > Wouldn't you need to call a separate procedural vote for whether
> > changes
> > > > cannot be allowed into 3.x without requiring they be submitted to 4.x
> > as
> > > > there was a disagreement there? Also, I am not sure that the
> procedural
> > > > vote argument can be used here for 4.x given that it involves
> > > modifications
> > > > to existing code. I would say we should drive towards getting a
> > consensus
> > > > by addressing the concerns folks have about 4.x.
> > > >
> > > > On Thu, Aug 31, 2017 at 8:24 PM, Thomas Weise <th...@apache.org>
> wrote:
> > > >
> > > > > There wasn't any more discussion on this, so here is the result:
> > > > >
> > > > > 1. Version 4.0 as major version change from 3.x
> > > > > ====================================
> > > > >
> > > > > +1 (7)
> > > > >
> > > > > Thomas Weise (PMC)
> > > > > Ananth G
> > > > > Vlad Rozov (PMC)
> > > > > Munagala Ramanath (committer)
> > > > > Pramod Immaneni (PMC)
> > > > > Sanjay Pujare
> > > > > David Yan (PMC)
> > > > >
> > > > > -1 (3)
> > > > >
> > > > > Amol Kekre (PMC)
> > > > > Sergey Golovko
> > > > > Ashwin Chandra Putta (committer)
> > > > >
> > > > >
> > > > > 2. Version 1.0 with simultaneous change of Maven artifact IDs
> > > > > ===============================================
> > > > >
> > > > > +1 (5)
> > > > >
> > > > > Thomas Weise (PMC)
> > > > > Ananth G
> > > > > Vlad Rozov (PMC)
> > > > > Munagala Ramanath (committer)
> > > > > David Yan (PMC)
> > > > >
> > > > > -1 (5)
> > > > >
> > > > > Pramod Immaneni (PMC)
> > > > > Sanjay Pujare
> > > > > Amol Kekre (PMC)
> > > > > Sergey Golovko
> > > > > Ashwin Chandra Putta (committer)
> > > > >
> > > > >
> > > > > RESULT
> > > > > =======
> > > > >
> > > > > Vote for option 1 (major version 4.x) *passes* with majority rule
> > [1].
> > > > >
> > > > > Thanks,
> > > > > Thomas
> > > > >
> > > > >
> > > > > [1] https://www.apache.org/foundation/voting.html
> > > > >
> > > > >
> > > > > On Mon, Aug 21, 2017 at 6:39 PM, Thomas Weise <th...@apache.org>
> > wrote:
> > > > >
> > > > > > This is to formalize the major version change for Malhar
> discussed
> > in
> > > > > [1].
> > > > > >
> > > > > > There are two options for major version change. Major version
> > change
> > > > will
> > > > > > rename legacy packages to org.apache.apex sub packages while
> > > retaining
> > > > > file
> > > > > > history in git. Other cleanup such as removing deprecated code is
> > > also
> > > > > > expected.
> > > > > >
> > > > > > 1. Version 4.0 as major version change from 3.x
> > > > > >
> > > > > > 2. Version 1.0 with simultaneous change of Maven artifact IDs
> > > > > >
> > > > > > Please refer to the discussion thread [1] for reasoning behind
> both
> > > of
> > > > > the
> > > > > > options.
> > > > > >
> > > > > > Please vote on both options. Primary vote for your preferred
> > option,
> > > > > > secondary for the other. Secondary vote can be used when counting
> > > > primary
> > > > > > vote alone isn't conclusive.
> > > > > >
> > > > > > Vote will be open for at least 72 hours.
> > > > > >
> > > > > > Thanks,
> > > > > > Thomas
> > > > > >
> > > > > > [1] https://lists.apache.org/thread.html/
> > > > bd1db8a2d01e23b0c0ab98a785f6ee
> > > > > > 9492a1ac9e52d422568a46e5f3@%3Cdev.apex.apache.org%3E
> > > > > >
> > > > >
> > > >
> > >
> >
>

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

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

On Fri, Sep 1, 2017 at 6:27 PM, Amol Kekre <am...@datatorrent.com> wrote:

> This vote was not done per process. The discussion was still on going. A
> decision that is more of code impact (consensus) is being called a
> procedural decision (majority vote). Moreover end of vote day/time was also
> not called ahead of the vote to determine when the vote ends. These seem to
> be a premise that only a few care about project. All red flags.
>
>
Facts for the benefit of others:

- Vote was originally opened for at least 72 hours (which to my knowledge
is standard)
- Vote was actually open for 10 days.
- It was opened after related discussions that go 6+ months back.
- Almost all folks that participated in those discussions also voted
- It was closed after there was no more discussion for 4 days.

Thomas

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

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

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

Thank you,

Vlad


On 9/1/17 18:27, Amol Kekre wrote:
> This vote was not done per process. The discussion was still on going. A
> decision that is more of code impact (consensus) is being called a
> procedural decision (majority vote). Moreover end of vote day/time was also
> not called ahead of the vote to determine when the vote ends. These seem to
> be a premise that only a few care about project. All red flags.
>
> Thks,
> Amol
>
>
> E:amol@datatorrent.com | M: 510-449-2606 | Twitter: @*amolhkekre*
>
> www.datatorrent.com
>
>
> On Fri, Sep 1, 2017 at 5:49 PM, Thomas Weise <th...@apache.org> wrote:
>
>> The first step in allowing a real community to grow would be to wear the
>> project hat, participate in discussions as individual, and consider how to
>> enable changes vs. trying to block active community members that contribute
>> on their own time from taking the project forward.
>>
>> Versioning and parallel release lines exist for a reason. Nothing needs to
>> be reinvented, everything that is needed to not disrupt existing users
>> while allowing for changes that evolve a product already exists.
>>
>> A number of folks don't wear the project hat, don't contribute in a
>> constructive manner and are otherwise not actively visible in the project.
>> Do they participate in this discussion out of their own interest or because
>> they are paid to do so? That combined with a look at the contributor stats
>> should provide a fairly good orientation.
>>
>> This discussion here is about making changes and evolve the project, not to
>> organize a DataTorrent & friends blockade. Put your own effort, research,
>> follow a discussion thread, present your own opinion. Separately, it will
>> be necessary to take up the topic of project independence at the PMC level.
>>
>> Thomas
>>
>>
>> On Fri, Sep 1, 2017 at 3:14 PM, Sandeep Deshmukh <
>> sandeep.deshmukh@gmail.com
>>> wrote:
>>> I totally agree with Sandesh. Things are being pushed when there is clear
>>> disagreement. If Apex has to grow the community, it can't grow using
>> divide
>>> and conquer method.
>>>
>>> On Fri, Sep 1, 2017 at 10:45 PM, Sandesh Hegde <sa...@datatorrent.com>
>>> wrote:
>>>
>>>> Using all the technicalities and loop holes, we can declare many votes
>>>> invalid. What purpose does it solve? This thread is dividing the
>>> community,
>>>> instead of recognizing the difference if we move forward with this,
>> there
>>>> is a chance that Apex will alienate many contributors. What's the end
>>> game
>>>> here? At what cost?
>>>>
>>>> On Fri, Sep 1, 2017 at 9:31 AM Thomas Weise <th...@apache.org> wrote:
>>>>
>>>>> Yes, you would need a separate discussion/vote on changes not being
>>>>> reflected in master that you make to a branch (current procedure).
>>>>>
>>>>> Regarding procedural vote, the decision to start development towards
>>> new
>>>>> major release is a longer term decision, not just code change.
>>>>>
>>>>> https://www.apache.org/foundation/glossary.html#MajorityApproval
>>>>>
>>>>> "Refers to a vote (sense 1) which has completed with at least three
>>>> binding
>>>>> +1 votes and more +1 votes than -1 votes. ( I.e. , a simple majority
>>>> with a
>>>>> minimum quorum of three positive votes.) Note that in votes requiring
>>>>> majority approval a -1 vote is simply a vote against, not a veto.
>>> Compare
>>>>> Consensus Approval. See also the description of the voting process."
>>>>>
>>>>>
>>>>> For code modifications the rules are different, -1 is a veto that
>> needs
>>>> to
>>>>> have a valid technical reason why the change cannot be made.
>> Otherwise
>>> it
>>>>> is void. None of the -1s in the vote result provide such
>> justification.
>>>>> Thanks,
>>>>> Thomas
>>>>>
>>>>>
>>>>>
>>>>> On Thu, Aug 31, 2017 at 10:06 PM, Pramod Immaneni <
>>>> pramod@datatorrent.com>
>>>>> wrote:
>>>>>
>>>>>> Thomas,
>>>>>>
>>>>>> Wouldn't you need to call a separate procedural vote for whether
>>>> changes
>>>>>> cannot be allowed into 3.x without requiring they be submitted to
>> 4.x
>>>> as
>>>>>> there was a disagreement there? Also, I am not sure that the
>>> procedural
>>>>>> vote argument can be used here for 4.x given that it involves
>>>>> modifications
>>>>>> to existing code. I would say we should drive towards getting a
>>>> consensus
>>>>>> by addressing the concerns folks have about 4.x.
>>>>>>
>>>>>> On Thu, Aug 31, 2017 at 8:24 PM, Thomas Weise <th...@apache.org>
>>> wrote:
>>>>>>> There wasn't any more discussion on this, so here is the result:
>>>>>>>
>>>>>>> 1. Version 4.0 as major version change from 3.x
>>>>>>> ====================================
>>>>>>>
>>>>>>> +1 (7)
>>>>>>>
>>>>>>> Thomas Weise (PMC)
>>>>>>> Ananth G
>>>>>>> Vlad Rozov (PMC)
>>>>>>> Munagala Ramanath (committer)
>>>>>>> Pramod Immaneni (PMC)
>>>>>>> Sanjay Pujare
>>>>>>> David Yan (PMC)
>>>>>>>
>>>>>>> -1 (3)
>>>>>>>
>>>>>>> Amol Kekre (PMC)
>>>>>>> Sergey Golovko
>>>>>>> Ashwin Chandra Putta (committer)
>>>>>>>
>>>>>>>
>>>>>>> 2. Version 1.0 with simultaneous change of Maven artifact IDs
>>>>>>> ===============================================
>>>>>>>
>>>>>>> +1 (5)
>>>>>>>
>>>>>>> Thomas Weise (PMC)
>>>>>>> Ananth G
>>>>>>> Vlad Rozov (PMC)
>>>>>>> Munagala Ramanath (committer)
>>>>>>> David Yan (PMC)
>>>>>>>
>>>>>>> -1 (5)
>>>>>>>
>>>>>>> Pramod Immaneni (PMC)
>>>>>>> Sanjay Pujare
>>>>>>> Amol Kekre (PMC)
>>>>>>> Sergey Golovko
>>>>>>> Ashwin Chandra Putta (committer)
>>>>>>>
>>>>>>>
>>>>>>> RESULT
>>>>>>> =======
>>>>>>>
>>>>>>> Vote for option 1 (major version 4.x) *passes* with majority rule
>>>> [1].
>>>>>>> Thanks,
>>>>>>> Thomas
>>>>>>>
>>>>>>>
>>>>>>> [1] https://www.apache.org/foundation/voting.html
>>>>>>>
>>>>>>>
>>>>>>> On Mon, Aug 21, 2017 at 6:39 PM, Thomas Weise <th...@apache.org>
>>>> wrote:
>>>>>>>> This is to formalize the major version change for Malhar
>>> discussed
>>>> in
>>>>>>> [1].
>>>>>>>> There are two options for major version change. Major version
>>>> change
>>>>>> will
>>>>>>>> rename legacy packages to org.apache.apex sub packages while
>>>>> retaining
>>>>>>> file
>>>>>>>> history in git. Other cleanup such as removing deprecated code
>> is
>>>>> also
>>>>>>>> expected.
>>>>>>>>
>>>>>>>> 1. Version 4.0 as major version change from 3.x
>>>>>>>>
>>>>>>>> 2. Version 1.0 with simultaneous change of Maven artifact IDs
>>>>>>>>
>>>>>>>> Please refer to the discussion thread [1] for reasoning behind
>>> both
>>>>> of
>>>>>>> the
>>>>>>>> options.
>>>>>>>>
>>>>>>>> Please vote on both options. Primary vote for your preferred
>>>> option,
>>>>>>>> secondary for the other. Secondary vote can be used when
>> counting
>>>>>> primary
>>>>>>>> vote alone isn't conclusive.
>>>>>>>>
>>>>>>>> Vote will be open for at least 72 hours.
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> Thomas
>>>>>>>>
>>>>>>>> [1] https://lists.apache.org/thread.html/
>>>>>> bd1db8a2d01e23b0c0ab98a785f6ee
>>>>>>>> 9492a1ac9e52d422568a46e5f3@%3Cdev.apex.apache.org%3E
>>>>>>>>


Thank you,

Vlad

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

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

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

Thks,
Amol


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

www.datatorrent.com


On Fri, Sep 1, 2017 at 5:49 PM, Thomas Weise <th...@apache.org> wrote:

> The first step in allowing a real community to grow would be to wear the
> project hat, participate in discussions as individual, and consider how to
> enable changes vs. trying to block active community members that contribute
> on their own time from taking the project forward.
>
> Versioning and parallel release lines exist for a reason. Nothing needs to
> be reinvented, everything that is needed to not disrupt existing users
> while allowing for changes that evolve a product already exists.
>
> A number of folks don't wear the project hat, don't contribute in a
> constructive manner and are otherwise not actively visible in the project.
> Do they participate in this discussion out of their own interest or because
> they are paid to do so? That combined with a look at the contributor stats
> should provide a fairly good orientation.
>
> This discussion here is about making changes and evolve the project, not to
> organize a DataTorrent & friends blockade. Put your own effort, research,
> follow a discussion thread, present your own opinion. Separately, it will
> be necessary to take up the topic of project independence at the PMC level.
>
> Thomas
>
>
> On Fri, Sep 1, 2017 at 3:14 PM, Sandeep Deshmukh <
> sandeep.deshmukh@gmail.com
> > wrote:
>
> > I totally agree with Sandesh. Things are being pushed when there is clear
> > disagreement. If Apex has to grow the community, it can't grow using
> divide
> > and conquer method.
> >
> > On Fri, Sep 1, 2017 at 10:45 PM, Sandesh Hegde <sa...@datatorrent.com>
> > wrote:
> >
> > > Using all the technicalities and loop holes, we can declare many votes
> > > invalid. What purpose does it solve? This thread is dividing the
> > community,
> > > instead of recognizing the difference if we move forward with this,
> there
> > > is a chance that Apex will alienate many contributors. What's the end
> > game
> > > here? At what cost?
> > >
> > > On Fri, Sep 1, 2017 at 9:31 AM Thomas Weise <th...@apache.org> wrote:
> > >
> > > > Yes, you would need a separate discussion/vote on changes not being
> > > > reflected in master that you make to a branch (current procedure).
> > > >
> > > > Regarding procedural vote, the decision to start development towards
> > new
> > > > major release is a longer term decision, not just code change.
> > > >
> > > > https://www.apache.org/foundation/glossary.html#MajorityApproval
> > > >
> > > > "Refers to a vote (sense 1) which has completed with at least three
> > > binding
> > > > +1 votes and more +1 votes than -1 votes. ( I.e. , a simple majority
> > > with a
> > > > minimum quorum of three positive votes.) Note that in votes requiring
> > > > majority approval a -1 vote is simply a vote against, not a veto.
> > Compare
> > > > Consensus Approval. See also the description of the voting process."
> > > >
> > > >
> > > > For code modifications the rules are different, -1 is a veto that
> needs
> > > to
> > > > have a valid technical reason why the change cannot be made.
> Otherwise
> > it
> > > > is void. None of the -1s in the vote result provide such
> justification.
> > > >
> > > > Thanks,
> > > > Thomas
> > > >
> > > >
> > > >
> > > > On Thu, Aug 31, 2017 at 10:06 PM, Pramod Immaneni <
> > > pramod@datatorrent.com>
> > > > wrote:
> > > >
> > > > > Thomas,
> > > > >
> > > > > Wouldn't you need to call a separate procedural vote for whether
> > > changes
> > > > > cannot be allowed into 3.x without requiring they be submitted to
> 4.x
> > > as
> > > > > there was a disagreement there? Also, I am not sure that the
> > procedural
> > > > > vote argument can be used here for 4.x given that it involves
> > > > modifications
> > > > > to existing code. I would say we should drive towards getting a
> > > consensus
> > > > > by addressing the concerns folks have about 4.x.
> > > > >
> > > > > On Thu, Aug 31, 2017 at 8:24 PM, Thomas Weise <th...@apache.org>
> > wrote:
> > > > >
> > > > > > There wasn't any more discussion on this, so here is the result:
> > > > > >
> > > > > > 1. Version 4.0 as major version change from 3.x
> > > > > > ====================================
> > > > > >
> > > > > > +1 (7)
> > > > > >
> > > > > > Thomas Weise (PMC)
> > > > > > Ananth G
> > > > > > Vlad Rozov (PMC)
> > > > > > Munagala Ramanath (committer)
> > > > > > Pramod Immaneni (PMC)
> > > > > > Sanjay Pujare
> > > > > > David Yan (PMC)
> > > > > >
> > > > > > -1 (3)
> > > > > >
> > > > > > Amol Kekre (PMC)
> > > > > > Sergey Golovko
> > > > > > Ashwin Chandra Putta (committer)
> > > > > >
> > > > > >
> > > > > > 2. Version 1.0 with simultaneous change of Maven artifact IDs
> > > > > > ===============================================
> > > > > >
> > > > > > +1 (5)
> > > > > >
> > > > > > Thomas Weise (PMC)
> > > > > > Ananth G
> > > > > > Vlad Rozov (PMC)
> > > > > > Munagala Ramanath (committer)
> > > > > > David Yan (PMC)
> > > > > >
> > > > > > -1 (5)
> > > > > >
> > > > > > Pramod Immaneni (PMC)
> > > > > > Sanjay Pujare
> > > > > > Amol Kekre (PMC)
> > > > > > Sergey Golovko
> > > > > > Ashwin Chandra Putta (committer)
> > > > > >
> > > > > >
> > > > > > RESULT
> > > > > > =======
> > > > > >
> > > > > > Vote for option 1 (major version 4.x) *passes* with majority rule
> > > [1].
> > > > > >
> > > > > > Thanks,
> > > > > > Thomas
> > > > > >
> > > > > >
> > > > > > [1] https://www.apache.org/foundation/voting.html
> > > > > >
> > > > > >
> > > > > > On Mon, Aug 21, 2017 at 6:39 PM, Thomas Weise <th...@apache.org>
> > > wrote:
> > > > > >
> > > > > > > This is to formalize the major version change for Malhar
> > discussed
> > > in
> > > > > > [1].
> > > > > > >
> > > > > > > There are two options for major version change. Major version
> > > change
> > > > > will
> > > > > > > rename legacy packages to org.apache.apex sub packages while
> > > > retaining
> > > > > > file
> > > > > > > history in git. Other cleanup such as removing deprecated code
> is
> > > > also
> > > > > > > expected.
> > > > > > >
> > > > > > > 1. Version 4.0 as major version change from 3.x
> > > > > > >
> > > > > > > 2. Version 1.0 with simultaneous change of Maven artifact IDs
> > > > > > >
> > > > > > > Please refer to the discussion thread [1] for reasoning behind
> > both
> > > > of
> > > > > > the
> > > > > > > options.
> > > > > > >
> > > > > > > Please vote on both options. Primary vote for your preferred
> > > option,
> > > > > > > secondary for the other. Secondary vote can be used when
> counting
> > > > > primary
> > > > > > > vote alone isn't conclusive.
> > > > > > >
> > > > > > > Vote will be open for at least 72 hours.
> > > > > > >
> > > > > > > Thanks,
> > > > > > > Thomas
> > > > > > >
> > > > > > > [1] https://lists.apache.org/thread.html/
> > > > > bd1db8a2d01e23b0c0ab98a785f6ee
> > > > > > > 9492a1ac9e52d422568a46e5f3@%3Cdev.apex.apache.org%3E
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>