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> 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> 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> 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> 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> 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> >> > >>> To: dev@phoenix.apache.org >> > >>> >> > >>> 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. >> > >>> >> > >> >> > >> -- busbey
