phoenix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Enis Söztutar <e...@apache.org>
Subject Re: [DISCUSS] Licensing in 4.8.0 rc0 (was Fwd: Re: [VOTE] Release of Apache Phoenix 4.8.0-HBase-1.2 RC0)
Date Tue, 19 Jul 2016 06:17:53 GMT
The licensing issues should affect all 4 RCs, so they all should fail or
succeed atomically. Having 4.8.0-HBase-0.98 with slightly different content
than 4.8.0-HBase-1.1, etc is just asking for trouble.

Thinking about this, doing the votes together makes sense. Otherwise, we
might end up with 4.8.0 meaning a different thing for different hbase
versions.

Enis

On Mon, Jul 18, 2016 at 10:34 PM, Sean Busbey <busbey@cloudera.com> wrote:

> Am I reading the tallies correctly?
>
> 0.98: pass with four +1s
> 1.0: pass with four +1s
> 1.1: fail with two +1s
> 1.2: pass with three +1s, one -1, and one non-binding -1
>
> This presumes I did not miss a vote cancellation from a release manager
> (which I've done in the past, tbf).
>
> As an aside, could we do these as a single vote in the future?
>
> --
> Sean Busbey
> On Jul 18, 2016 17:47, "Josh Elser" <josh.elser@gmail.com> wrote:
>
> > Thanks for the response, Andrew!
> >
> > I've started knocking out the source-release issues. Will put up a patch
> > with how far I get tonight.
> >
> > Andrew Purtell wrote:
> >
> >> With PMC hat on I am -1 releasing with known policy violations. This is
> >> the same position I took when it was HBase releases at issue. Option 1
> is
> >> not a good option. Let's go with another.
> >>
> >>
> >> On Jul 18, 2016, at 1:53 PM, Josh Elser<elserj@apache.org>  wrote:
> >>>
> >>> (Moving this over to its own thread to avoid bogging down the VOTE
> >>> further)
> >>>
> >>> PMC, what say you? I have cycles to work on this now.
> >>>
> >>> -------- Original Message --------
> >>> Subject: Re: [VOTE] Release of Apache Phoenix 4.8.0-HBase-1.2 RC0
> >>> Date: Mon, 18 Jul 2016 14:43:54 -0400
> >>> From: Josh Elser<josh.elser@gmail.com>
> >>> To: dev@phoenix.apache.org
> >>>
> >>> Sean Busbey wrote:
> >>>
> >>>> On Mon, Jul 18, 2016 at 12:05 PM, Ankit Singhal
> >>>> <ankitsinghal59@gmail.com>   wrote:
> >>>>
> >>>>> Now we have three options to go forward with 4.8 release (or whether
> to
> >>>>> include licenses and notices for the dependency used now or later):-
> >>>>>
> >>>>> *Option 1:- Go with this RC0 for 4.8 release.*
> >>>>>         -- As the build is functionally good and stable.
> >>>>>         -- It has been delayed already and there are some project
> >>>>> which are
> >>>>> relying on this(as 4.8 works with HBase 1.2)
> >>>>>         -- We have been releasing like this from past few releases.
> >>>>>         -- RC has binding votes required for go head.
> >>>>>         -- Fix license and notice issue in future releases.
> >>>>>
> >>>>
> >>>> I would *strongly* recommend the PMC not take Option 1's course of
> >>>> action. ASF policy on necessary licensing work is very clear.
> >>>> Additionally, if the current LICENSE/NOTICE work is sufficiently
> >>>> inaccurate that it fails to meet the licensing requirements of bundled
> >>>> works then the PMC will have moved from accidental nonconformance in
> >>>> prior releases to knowingly violating the licenses of those works in
> >>>> this release. Reading the JIRAs that Josh was helpful enough to file,
> >>>> it sounds like the current artifacts would in fact violate the
> >>>> licenses of bundled works.
> >>>>
> >>> In case my opinions weren't already brutally clear: the issue is not
> the
> >>> functionality of the software "Apache Phoenix". This issue is that this
> >>> release candidate clearly violates ASF policy. Quite certainly option
> >>> one would result in escalation to the board -- I don't know how that
> >>> will play out. It's not meant to be a threat, either, but a reality.
> >>> This is one of the core responsibilities of the PMC. There really isn't
> >>> any wiggle room.
> >>>
> >>> I can start knocking out the issues I created -- I really don't think
> >>> this will take more than a day or two for the source release and the
> >>> binary artifact.
> >>>
> >>
>

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