impala-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From John Russell <>
Subject Re: [VOTE] 2.8.0 release candidate 1
Date Tue, 10 Jan 2017 02:30:25 GMT

> On Jan 9, 2017, at 4:44 PM, Jim Apple <> wrote:
>> 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?
> Can you help me understand what you mean by "prospects for that”?

I mean the prospects for making release candidate 2 with selected doc changes applied.  If
status of docs was not a blocker either way (since we did put that disclaimer on the front
that cleanup is still underway), perhaps existing +1 votes could carry over without a lot
of retesting.

> To the first, I do not know, to the second, I suspect not.
>> What’s the best way to manage that process — try to get other people to agree
and -1 until those reviews are finished
> While I think I will still be a non-binding +1 to rc1, I certainly
> won't take offense if you advocate for what you think is right.
> Perhaps other would be more frustrated.

I don’t know how much work is involved in doing some cherry-picks and preparing an RC2.
 That’s why I’m flexible regarding my vote.  2.7 went out with no doc source at all. 
2.8 we already determined will go out with imperfect doc source.  The question is, is it worth
making another release candidate with the docs closer to perfection than currently.  I think
users will be happier if we can manage to fold these changes in.

There could be some other high-value doc ones landing this week, which I suggest we also consider
on a case-by-case basis for inclusion in an RC2.  For example, I just posted gerrit # 5661
which fixes all the “CDH 5.5 and higher” wording in headings to refer to Impala release


>> get the doc changes into 2.8.1
> There may or may not be a 2.8.1. A necessary, but not sufficient,
> pre-requisite to a release is that a committer volunteers to manage
> it.
>> or have some parallel track where doc changes continue to be integrated sometime
before the incubator PMC vote?
> I don't think the incubator PMC will even hold a vote on a release
> tarball that wan't first approved by the PPMC.

View raw message