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 >
