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:a...@datatorrent.com | M: 510-449-2606 | Twitter: @*amolhkekre* www.datatorrent.com On Fri, Sep 1, 2017 at 5:49 PM, Thomas Weise <t...@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.deshm...@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 <sand...@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 <t...@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 < > > > pra...@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 <t...@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 <t...@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 > > > > > > > > > > > > > > > > > > > > > > > > > > > >
