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
