It seems like we're generally on-track for code freeze on 8/27. Of course that generally means that we need to have any PRs expected in the upcoming release to be in place by end of day today so that they have time for review. The biggest piece outstanding is still TINKERPOP-1278 which marko, dave brown, and i are still tweaking on a bit. I suggest we not issue that as a PR by the way. It is too massive a body of work to review via GitHub. I think we should just do the review through a DISCUSS thread prior to merging back to master.
We also need to review/merge in a few open (and excellent) PRs by Robert Dale: https://github.com/apache/tinkerpop/pull/384 https://github.com/apache/tinkerpop/pull/385 Finally, I still need votes for this netty bump: https://github.com/apache/tinkerpop/pull/387 If you have any outstanding work that you expect to drop soon, please let everyone know on this thread. Thanks! On Wed, Aug 10, 2016 at 11:52 AM, Pieter Martin <[email protected]> wrote: > I too am fine with the proposed dates. > > Thanks > Pieter > > Excerpts from Stephen Mallette's message of August 10, 2016 3:55 : > > Labor Day - true. I'm fine with 9/6 - I'd probably be the one initiating >> the vote and I doubt i'd get to do that on the holiday so 9/6 is more >> likely. >> >> On Wed, Aug 10, 2016 at 9:51 AM, Ted Wilmes <[email protected]> wrote: >> >> Hello, >>> I think 9/5 is Labor Day. I'm wondering if we should keep the freeze on >>> 8/27 but move >>> the start of vote to 9/6. Not a big deal, but maybe some more folks >>> (non-committers) would >>> be around and see the vote thread started up if they wanted to test >>> things >>> out. As far as >>> shorter release cycles going forward, I think that makes good sense. >>> >>> Thanks, >>> Ted >>> >>> On Tue, Aug 9, 2016 at 2:11 PM, Stephen Mallette <[email protected]> >>> wrote: >>> >>> > When we went through vote on 3.1.3/3.2.1, we'd discussed releasing >>> > 3.2.2/3.1.4 on a shorter release period than normal. A shorter release >>> > cycle for these two versions would allow us to quickly address a bug or >>> two >>> > found late in code freeze. Perhaps longer term, shorter release cycles >>> > might help produce less stress around getting PRs in for code freeze as >>> > there would be an expectation that another release would follow with >>> > reasonable speed. >>> > >>> > I'd like to propose that we start code freeze 8/27 and go to vote on >>> 9/5. >>> > I'll just mention that I could only see those dates slipping a little >>> bit >>> > if TINKERPOP-1278 runs into troubles, but right now I think that's on >>> track >>> > to get merged back to master in time for that deadline. >>> > >>> > Any thoughts? >>> > >>> > Thanks, >>> > >>> > Stephen >>> > >>> >>> >>
