Awesome - thanks, Josh -- great job! On Thu, Jul 21, 2016 at 1:27 PM, Josh Elser <josh.el...@gmail.com> wrote:
> Done! > > Thanks to everyone who stepped up to help with this process to make sure > Apache Phoenix is doing the most we can to respect licensing. > > > James Taylor wrote: > >> That was super nice of Sean! Great job and thanks for jumping on this. I'm >> +1 on having it committed. >> >> On Thu, Jul 21, 2016 at 11:16 AM, Josh Elser<josh.el...@gmail.com> >> wrote: >> >> Sean Busbey was a fine gent and gave me some great feedback this morning. >>> I think it's in a good place -- does anyone else want to look at it >>> before >>> I merge it? >>> >>> >>> Josh Elser wrote: >>> >>> From a packaging perspective, I think this is good to go. >>>> >>>> https://github.com/apache/phoenix/pull/183 >>>> >>>> I've asked a few fine individuals who I respect a bit in this area to >>>> take a look. I'm happy to explain any changes to those here who would >>>> like to understand why these are appropriate. >>>> >>>> Meanwhile, I'll run a few tests myself to make sure the code is still >>>> working as intended :) >>>> >>>> Josh Elser wrote: >>>> >>>> A quick update from me for those not watching the JIRA issues: >>>>> >>>>> I've found two LGPL dependencies that have been bundled in the binary >>>>> artifact which *must* not be included as they are not compatible with >>>>> the Apache Software License. [1] >>>>> >>>>> phoenix-core has a dependency on net.sourceforge.findbugs:annotations >>>>> which provides an implementation for JSR-305. Thankfully, there is an >>>>> ASL clean-room implementation we can use instead (looks like HBase had >>>>> already dealt with this at one point in time). >>>>> >>>>> phoenix-pherf has a dependency on org.jfree:jfreechart for some >>>>> charting >>>>> (I assume). There is no drop-in replacement that I am aware of here. >>>>> Unless someone can step up to swap out jfreechart for something that is >>>>> compatibly licensed, I will remove it outright. >>>>> >>>>> Two great examples about why keeping a close eye on this stuff is super >>>>> important. >>>>> >>>>> [1] http://www.apache.org/legal/resolved.html#category-x >>>>> [2] https://issues.apache.org/jira/browse/PHOENIX-3101 >>>>> [3] https://issues.apache.org/jira/browse/PHOENIX-3102 >>>>> >>>>> James Taylor wrote: >>>>> >>>>> Ok, that's great then. We can just combine the separate vote emails >>>>>> into >>>>>> one then. Much easier. >>>>>> Thanks, >>>>>> James >>>>>> >>>>>> On Tuesday, July 19, 2016, Josh Elser<josh.el...@gmail.com> wrote: >>>>>> >>>>>> Agreed with Sean. There's no reason that I'm aware of that each target >>>>>> >>>>>>> HBase version has to be its own VOTE thread. The semantics of >>>>>>> "all-or-none" would definitely seem logical to be encapsulated in one >>>>>>> vote thread. >>>>>>> >>>>>>> On Tue, Jul 19, 2016 at 9:26 AM, Sean Busbey<bus...@cloudera.com >>>>>>> <javascript:;>> wrote: >>>>>>> >>>>>>> AFAIK, PMCs can organize their VOTEs as they please. The only >>>>>>>> requirement I'm aware of is being able to point at a VOTE that >>>>>>>> covers >>>>>>>> the release. I don't see why a single VOTE that covers multiple git >>>>>>>> REFs and multiple artifacts (even in different directories on >>>>>>>> dist.apache) would be a problem. I can think of one case where this >>>>>>>> was done before (Apache NiFi; I think they were in the incubator at >>>>>>>> the time). >>>>>>>> >>>>>>>> Agreed that this kind of process change doesn't need to be blocking. >>>>>>>> It's just confusing that right now we can end up with a mixed vote >>>>>>>> result across hbase compatibility layers (although I guess that >>>>>>>> could >>>>>>>> be considered a feature if a fatal compability-layer-specific bug >>>>>>>> were >>>>>>>> to show up). >>>>>>>> >>>>>>>> On Tue, Jul 19, 2016 at 1:33 AM, James Taylor< >>>>>>>> jamestay...@apache.org >>>>>>>> >>>>>>>> <javascript:;>> wrote: >>>>>>> >>>>>>> If we could have a single vote, that'd be great, but I didn't think >>>>>>>> >>>>>>>>> that >>>>>>>>> was possible. Would we be voting on the union of all the source >>>>>>>>> codes >>>>>>>>> across all four branches? Is it acceptable to be voting on multiple >>>>>>>>> hash/tags (since they're in different branches)? What about binary >>>>>>>>> >>>>>>>>> release? >>>>>>>> We'd have multiple tar files, one per branch. >>>>>>>> >>>>>>>>> There's a fair amount of automation and process already developed >>>>>>>>> for >>>>>>>>> >>>>>>>>> our >>>>>>>> release procedure. This is the way we've been doing things for the >>>>>>>> >>>>>>>>> last >>>>>>>>> >>>>>>>>> 10+ >>>>>>>> releases (for good or for bad). Unless the new process would be >>>>>>>> >>>>>>>>> more or >>>>>>>>> less the same as the old, I think we need to get 4.8.0 out first >>>>>>>>> >>>>>>>>> (following >>>>>>>> all ASF policies, of course), before changing our documentation, >>>>>>>> >>>>>>>>> automation, etc. >>>>>>>>> >>>>>>>>> On Tue, Jul 19, 2016 at 8:17 AM, Enis Söztutar<e...@apache.org >>>>>>>>> >>>>>>>>> <javascript:;>> wrote: >>>>>>>> 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<bus...@cloudera.com >>>>>>>>>> >>>>>>>>>> <javascript:;>> 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.el...@gmail.com >>>>>>>>>>> >>>>>>>>>>> <javascript:;>> 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<els...@apache.org >>>>>>>>>>>>> >>>>>>>>>>>>> <javascript:;>> 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.el...@gmail.com<javascript:;>> >>>>>>>>>>>>>> To: dev@phoenix.apache.org<javascript:;> >>>>>>>>>>>>>> >>>>>>>>>>>>>> Sean Busbey wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>> On Mon, Jul 18, 2016 at 12:05 PM, Ankit Singhal >>>>>>>>>>>>>> >>>>>>>>>>>>>>> <ankitsingha...@gmail.com<javascript:;>> 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. >>>>>>>> >>>>>>>>> >>>>>>>>>>>>>> -- >>>>>>>> busbey >>>>>>>> >>>>>>>> >>
