+1 On Wed, Dec 7, 2016 at 8:16 PM Jean-Daniel Cryans <[email protected]> wrote:
> +1, let's get a 1.2.x branch soon. > > J-D > > On Tue, Dec 6, 2016 at 8:44 PM, Todd Lipcon <[email protected]> wrote: > > > Hi Kudu developers, > > > > Back in mid-October I proposed a plan for the 1.1 and 1.2 releases[1]. > 1.1 > > is now behind us, so I wanted to start a thread regarding 1.2. > > > > The original proposal was to aim for a 1.2 release for mid-January. While > > it was always planned to be a time-based release, we also discussed that > > we’d likely be able to get some of the security features into it, as well > > as a bunch of other work completed that’s been in flight the last month > or > > two. > > > > Now that we’re getting a bit closer, I want to re-evaluate the timing and > > scope a bit. Although we made some good progress on security features, > > things have slowed a bit in recent weeks as people have shifted focus > onto > > other critical improvements and issues. Given that, and the fact that a > lot > > of people will be out for multiple weeks in December due to holidays, I > > don’t think it’s realistic to guess that we’ll complete (and fully > > test/stabilize) the security work in time for a mid-Jan release date. > > > > On the other hand, there has been a lot of other good work in master > > recently, both in terms of features as well as bug fixes. Here’s an > > incomplete list of features and improvements from my skim of the git log > > since 1.1.0 which are either complete or almost-complete: > > > > - Improved consistency of reads (snapshot consistency / read-your-writes) > > - File descriptor cache and container size limiting to prevent file > system > > corruption on RHEL 6 > > - Ability to bound memory usage for errors in C++ client (new API) > > - Ability to list range partitions in Java API (new API) > > - Performance improvements (AVX2) for BITSHUFFLE and DICT encoding > > - Validation and “guard rails” for table metadata, column names, etc. > > > > There are also a bunch of bug fixes, some of which might be a bit risky > to > > cherry-pick into a 1.1.x release due to the complexity of the patches. > I’ve > > spent a good amount of my last several weeks working on stress testing > the > > master branch, and can tell you that it’s significantly better than 1.1. > > > > So, even without the security work complete, I think we’ve already got > > enough juicy stuff lined up for 1.2 to make it enticing for users to > > upgrade. We can then push the security work out to 1.3 some time in early > > 2017. > > > > So, the next question is timing. I’d like to propose that we cut a > > branch-1.2 from master this week, and give it a couple weeks of soak time > > before release. This differs from previous releases in which we’ve cut a > > branch only a day or two before the release candidate. My reasoning is as > > follows: > > > > 1) Some of the changes since 1.1 have been fairly invasive. In > particular, > > the consistency work has done surgery on where and how timestamps are > > assigned to writes, and a bug here could result in replicas diverging, > > crashes, deadlocks, etc. Having a bit of time to soak, stress test, and > > correctness-test this work before releasing it to the community would be > > prudent. > > > > 2) Now that we are post-1.0, we have more and more users depending on > Kudu > > for production (or almost-production) workloads. As we enter a stage of > > greater maturity, it’s probably smart to give each release a bit more > > “soak” in a branch before giving it to users. > > > > 3) Given that a bunch of the above-mentioned features are currently > > wrapping up, we’ll probably get back to working on authentication > features, > > which will cause quite a bit of churn. It would be better to avoid > exposing > > the upcoming 1.2 branch to this churn, and branching early is a good way > to > > insulate it. > > > > Thoughts? > > > > -Todd > > > > > > [1] http://www.mail-archive.com/[email protected]/msg00237.html > > >
