I hope it is okay if I separate this into two topics. (1) Is the release okay I'd say it is on the border. The source release itself has internal instructions on how to build via README --> HOWTO. These instructions don't work for half the world. If everyone else is okay with it, I am. I hate having releases shot down on the general list and I've had one shot before for this type of issue. If all the +1's for the release are onboard with this, we should simply note it when the vote is started on the general list. But procedurally, I absolutely agree that Julian is fine to proceed if others have no additional responses on this thread in the 24h.
(2) If a PMC member expresses concerns about a release artifact, how would we like to proceed in the future? Two options I've seen that work are: a) Extend the vote until we reach either a conclusion (or an extended silence). b) PMC should immediately state an initial -1 vote and state that their vote can be changed based on other's feedback. I was taking the approach (a) while it seems like Julian would prefer (b). What do others think works well? Nick, Jesus and John, you're all members of the Hive and/or HBase communities, what works well in those communities? On Sat, Apr 11, 2015 at 9:57 AM, Julian Hyde <[email protected]> wrote: > Let's extend the discussion for a further 24 hours. > > Procedurally, I don't think I can withdraw the result of the 1.2 RC1 > vote but if we can't reach lazy consensus in 24 hours (ending 10am > Pacific on Sunday) I will discard RC1 and move on to an RC2. > > And for what it's worth, I believe that I was justified in calling the > RC1 vote. We had the required excess of binding +1 votes over binding > -1 votes, and as release manager I made the call that I thought the > release was sound. After you expressed your reservations, Vladimir and > Nick cast +1 votes. However, I now think I should have recorded your > vote as -0. > > As for whether RC1 is suitable to be released. I argue that the > documented build process succeeds because I intend to include a > mention of CALCITE-677 and its workaround in the release announcement. > > Here are my arguments for why the release is sound. Calcite is on a > short (1 month) release cycle and there are projects that depend on > this release (Hive and now Phoenix). Yes, that affects my judgement > about whether the release is fit for purpose, and it should. > Engineering is a compromise. One line in the release notes documenting > a workaround to a minor, locale-specific problem, in new > functionality, that will be fixed in a release in less than a month, > is better, in my opinion, than several days delay in the release, an > extra day of my time to create a new RC and several hours of other > people's time to vote on it. > > I would like to hear what the rest of the community thinks. To repeat, > we can not change the result of the RC1 vote at this point, but it we > cannot reach consensus in 24 hours I will discard RC1 and move on to > an RC2. > > Julian > > > On Fri, Apr 10, 2015 at 7:30 PM, Jacques Nadeau <[email protected]> > wrote: > > I didn't do an immediate -1 because I wanted to have a discussion. Not > > waiting for the discussion to complete before calling the vote was > > unfortunate. > > > > What was the big exception to spinning another release? To me, an Apache > > release's two most important criteria are correct licensing and a default > > build that works. > > On Apr 10, 2015 10:14 AM, "Julian Hyde" <[email protected]> wrote: > > > >> I'd rather press ahead with the release. This is a minor issue in new > >> functionality, and shows up in the test suite (not the build per se). > >> I've logged https://issues.apache.org/jira/browse/CALCITE-677 and will > >> mention it in the release notes. > >> > >> On Fri, Apr 10, 2015 at 8:34 AM, Jacques Nadeau <[email protected]> > >> wrote: > >> > Build fails seems like a showstopper to me, especially if the fix is > one > >> > liner. Would rather redo here than have the Incubator general shoot it > >> > down. > >> > On Apr 10, 2015 2:13 AM, "Vladimir Sitnikov" < > >> [email protected]> > >> > wrote: > >> > > >> >> I've added @Ignore to the particular test and it went through. > >> >> It's a bit annoying to break "mvn install", however I would not > >> >> consider that a show-stopper either. > >> >> > >> >> Build works, mat-calcite-plugin works with Calcite 1.2.0-incubating. > >> >> > >> >> I would consider several modifications to mvn poms (see [1]), however > >> >> those do not block the release either. > >> >> > >> >> +1 for the release > >> >> > >> >> [1]: > >> >> > >> > https://issues.apache.org/jira/browse/CALCITE-619?focusedCommentId=14489188&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14489188 > >> >> > >> >> Vladimir > >> >> > >> >
