apex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Pramod Immaneni <pra...@datatorrent.com>
Subject Re: [RESULT] [VOTE] Major version change for Apex Library (Malhar)
Date Fri, 01 Sep 2017 18:34:06 GMT
My response inline

On Fri, Sep 1, 2017 at 9:31 AM, Thomas Weise <thw@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).
>

I don't think this was requested as a general policy and it doesn't need to
be termed that way. Between 3.x and 4.x should suffice.


>
> Regarding procedural vote, the decision to start development towards new
> major release is a longer term decision, not just code change.
>

Longer term decision does not mean procedural change. You can have changes
that can be proposed as being beneficial in the long term which still
manifest in code changes now such as this one. Example of procedural
changes would be, steps a contributor should follow to submit code, steps a
committer should follow, jira filing process, release processes etc., the
kind of updates you made recently in the contribution guidelines on the
apex site.


>
> 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."
>

If it not a procedural change this wouldn't apply.


>
> 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.
>

This does involve code changes as the code in the master would change so I
don't think we can say it is not a code modification. I suggest we have a
discussion on whether relaxing the 3.x checkins would be sufficient for
folks who have raised objection and if it will change their vote from -1
before moving forward.


>
> 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 <thw@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 <thw@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
> > > >
> > >
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message