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
