Sounds good to me too. In addition to what has already been pointed out about the Spark History Server and the Kubernetes support, this would also give us enough time to further polish the new data source v2 API and the vectorized UDF API to iron out any kinks.
I'd like to volunteer to serve as the release manager for Spark 2.3. In terms of bandwidth, I will be available during this holiday season as I have no vacation planed during the Dec-Jan timeframe. And I'm fairly familiar with most of the major efforts targeted for the 2.3 release. Thanks, Sameer On Fri, Nov 10, 2017 at 2:07 AM, Sean Owen <so...@cloudera.com> wrote: > The original timeline was just +6 months from last planned release, so > there was nothing too magic about it. That was pushed from +4 . The only > risk here is that an extra month becomes 2, 3, and so users aren't getting > the other 1000 fixes. But no particular problem with moving it back. > > On Thu, Nov 9, 2017, 5:54 PM Michael Armbrust <mich...@databricks.com> > wrote: > >> According to the timeline posted on the website, we are nearing branch >> cut for Spark 2.3. I'd like to propose pushing this out towards mid to >> late December for a couple of reasons and would like to hear what people >> think. >> >> 1. I've done release management during the Thanksgiving / Christmas time >> before and in my experience, we don't actually get a lot of testing during >> this time due to vacations and other commitments. I think beginning the RC >> process in early January would give us the best coverage in the shortest >> amount of time. >> 2. There are several large initiatives in progress that given a little >> more time would leave us with a much more exciting 2.3 release. >> Specifically, the work on the history server, Kubernetes and continuous >> processing >> 3. Given the actual release date of Spark 2.2, I think we'll still get >> Spark 2.3 out roughly 6 months after. >> >> Thoughts? >> >> Michael >> > -- Sameer Agarwal Software Engineer | Databricks Inc. http://cs.berkeley.edu/~sameerag