A procedural question. I would recommend getting the documentation changes from gerrits # 5644, 5646, and 5649 into the 2.8 release. That will give us some solidity w.r.t. the Impala + Kudu changes and other new features. What are the prospects for that if it takes, say, to the end of the week to close out those reviews?
What’s the best way to manage that process — try to get other people to agree and -1 until those reviews are finished, let 2.8.0 proceed because 2.8.0 is time-sensitive and get the doc changes into 2.8.1, or have some parallel track where doc changes continue to be integrated sometime before the incubator PMC vote? Thanks, John > On Jan 7, 2017, at 11:46 AM, Jim Apple <[email protected]> wrote: > > This is a vote to release 2.8.0. The artifacts for testing are at > <https://dist.apache.org/repos/dist/dev/incubator/impala/2.8.0/RC1/>. > That is git tag 2.8.0-rc1, tree hash > cc8de358d5c64778d171ad47aa6b513d437ac4b0, visible at > <https://git-wip-us.apache.org/repos/asf?p=incubator-impala.git;a=tree;h=cc8de358d5c64778d171ad47aa6b513d437ac4b0>. > > Please vote +1 or -1. -1 votes should be accompanied by an explanation > of the reason. Only PPMC members and mentors have binding votes, but > other community members are encouraged to cast non-binding votes. This > vote will pass if there are 3 binding +1 votes and more binding +1 > votes than -1 votes. > > This wiki page describes how to check the release before you vote: > https://cwiki.apache.org/confluence/display/IMPALA/DRAFT%3A+How+to+Release > > The vote will be open until the end of Wednesday, January 11, > California time. Once the vote passes the Impala PPMC vote, it still > must pass the incubator PMC vote before a release is made.
