Yes. We can't have happen AGAIN what we had happen on this release and unfortunately, on the last release too.
The number 1 most despicable human quality (in my book) -- procrastination. If something is due in a year, get it done 6 months early. If its due in a week, have it done the next day. If its due now, learn to reverse time and get it done when the dinosaurs roamed. The date something is due is not the date its due, its the date its late. With that -- we can't have people merging the night before w/o doing full integration tests, doc builds. Its not everyone else's responsibility to scramble to fix people's last minute problems. Get your work done early, have it tested, have the docs building, have it all pretty and perfect for the releaser. Nothing is more demoralizing then going to do the release (which is demoralizing in itself) to only see that tests aren't passing, docs aren't building… that is just straight wrong (disrespectful). Anything that prevents procrastinators from getting their dirty little deranged hands on the TinkerPop flow -- I am all about it. Marko. http://markorodriguez.com On Oct 16, 2015, at 7:29 AM, Stephen Mallette <spmalle...@gmail.com> wrote: > To improve on our release process a bit and to make things a bit less > hectic for the "release manager" on release day I've been documenting a few > things I've done this week in preparation for 3.0.2. > > https://github.com/apache/incubator-tinkerpop/blob/tp30/RELEASE.asciidoc#pre-flight-check > > I'd like to include in this list something that Matt Frantz had suggested > when we released 3.0.1 - code freeze 1 week prior to release. To be more > specific, I think that means that we should stop changes to actual "code" > the day we begin the pre-flight check. Documentation tweaks and other > knick-knacks would still be fair game, but I think we reduce some > risk/headache by placing this limit on ourselves. > > So, I guess this thread is about two things: > > 1. What do you think of my pre-flight checks? Should anything be added? > 2. Should we implement Matt Frantz's suggestion and institute a 1 week code > freeze prior to release?
