Switching my vote to -1. Our releases need to conform to ASF policy. Besides the stuff that Josh is already doing (thanks so much, Josh), my recommendation would be to: - cancel the vote on the current release. Ankit - as RM would you mind doing that? - remove the trace UI module from both the source and binary releases as it's the cause of the majority of issues. - don't tackle the automation issue yet as we need to get 4.8.0 out ASAP - it's late as it is.
Thanks, James On Tue, Jul 19, 2016 at 1:47 AM, Andrew Purtell <apurt...@apache.org> wrote: > Option #2 looks ok but I think implied it is source release only, right? > > Option #3 is the full solution so that's fine. > > On Mon, Jul 18, 2016 at 4:46 PM, Andrew Purtell <apurt...@apache.org> > wrote: > > > Carrying this over from the discussion. > > > > -1 (binding) > > > > Option 1 isn't viable. Getting IP right in a release is fundamental. > > > > > > On Mon, Jul 18, 2016 at 11:43 AM, Josh Elser <josh.el...@gmail.com> > wrote: > > > >> Sean Busbey wrote: > >> > >>> On Mon, Jul 18, 2016 at 12:05 PM, Ankit Singhal > >>> <ankitsingha...@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. > >> > > > > > > > > -- > > Best regards, > > > > - Andy > > > > Problems worthy of attack prove their worth by hitting back. - Piet Hein > > (via Tom White) > > > > > > -- > Best regards, > > - Andy > > Problems worthy of attack prove their worth by hitting back. - Piet Hein > (via Tom White) >
