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