On Mon, Sep 26, 2016 at 10:49 AM, Dan Burkert <danburk...@apache.org> wrote:
> Hi all, > > Since the 1.0.0 release there have been a few issues found which may > warrant a bug fix on the 1.0.x line. I'd like to get the ball rolling and > figure out what we might want to include in a bug release, if we decide to > go ahead with a bug release fix. > > Potential inclusions: > > KUDU-1652 <https://issues.apache.org/jira/browse/KUDU-1652>: Partition > pruning / scan optimization fails with IS NOT NULL predicate on PK column > KUDU-1651 <https://issues.apache.org/jira/browse/KUDU-1651>: tserver crash > when pushing predicate on dict encoded block with all null values > 8fc75a5c65 > <https://github.com/apache/kudu/commit/8fc75a5c654e100871316e61878b14 > 1df4707d0e>: > [java > client] Fix an NPE in KuduException > 9911c489 > <https://github.com/apache/kudu/commit/9911c489c45b3a261ee50ad1f83738 > 7b4953421b> > KUDU-1623 <https://issues.apache.org/jira/browse/KUDU-1623>: Properly > handle UPSERTS that only include PK column > b0b273e8 > <https://github.com/apache/kudu/commit/b0b273e8271752b6eb04ba163981aa > d1c792e413>: > [java client] make DateFormat safe to use > 1eb2418 > <https://github.com/apache/kudu/commit/1eb24183a540f4e3bbbc8a399e440e > cf905f6129>: > consensus: properly truncate all state when aborting operations > KUDU-1090 <https://issues.apache.org/jira/browse/KUDU-1090> 4b9d2f6 > <https://github.com/apache/kudu/commit/4b9d2f6976f45ea57e9a2c2648f31b > 3a0941a569>: > relax > MemTracker uniqueness constraint > > It would also be nice to fix the Java client's client2tablet > synchronization / memory leak issue, but I'm not sure of the proper set of > patches to backport. JD/David, do you have any insight on that? > The two patches that fixed the leak and caused a lot of issues were reverted in the 1.0 branch, I'd rather keep things the way they are since the leak's not really a new issue. > > Please reply with any other commits that you would like to include. > > Most of these issues are extremely rare, or easily worked around (or both), > but I think in aggregate they represent enough sharp edges that waiting for > a 1.1 release may be painful. > +1 > > Since a few of these issues don't have a patch committed or even in review > yet, an RC probably can't be cut before the end of next week (October > 7th). I volunteer to RM this one. What does everyone think? > +1, good on you Dan :) J-D
