Hi Vinod, On Fri, Aug 25, 2017 at 2:42 PM, Vinod Kumar Vavilapalli <vino...@apache.org > wrote:
> > From a release management perspective, it's *extremely* reasonable to > block the inclusion of new features a month from the planned release date. > A typical software development lifecycle includes weeks of feature freeze > and weeks of code freeze. It is no knock on any developer or any feature to > say that we should not include something in 3.0.0. > > > We have never followed the ‘typical' lifecycle that I am guessing you are > referring to. If we are, you'll need to publish some of the following: a > feature freeze date, blockers-criticals-only-from-now date, > testing-finish date, documentation-finish date, final release date and so > on. > We discussed this as part of the 3.0 alpha/beta/GA plan. The point of the extended alpha/beta process was to release on a schedule. Things that weren't ready could be merged for the next alpha. I also advertised alpha4 as feature complete and beta1 as code complete so we could quickly move on to GA. > What we do with Apache releases typically is instead we say ‘this' is > roughly when we want to release, and roughly what features must land and > let the rest figure out itself. > > We did this too. We defined the original scope for 3.0.0 GA way back when we started the 3.0.0 release process. I've been writing status updates on the wiki and tracking targeted features and release blockers throughout. The target versions of this recent batch of features were not discussed with me, the release manager, until just recently. After some discussion, I think we've arrived at a release plan that everyone's happy with. But, I want to be clear that late-breaking inclusion of additional scope should be considered the exception rather than the norm. Merging code so close to release means less time for testing and validation, which means lower quality releases. I don't think it's a lot to ask that feature leads shoot an email to the release manager of their target version. DISCUSS emails right before a proposed merge VOTE are way too late, it ends up being a fire drill where we need to scramble on many fronts. > Neither is right or wrong. If we want to change the process, we should > communicate as such. > > Proposing a feature freeze date on the fly is only going to confuse > people. > > > I've been very open and clear about the goals, schedule, and scope of > 3.0.0 over the last year plus. The point of the extended alpha process was > to get all our features in during alpha, and the alpha merge window has > been open for a year. I'm unmoved by arguments about how long a feature has > been worked on. None of these were not part of the original 3.0.0 scope, > and our users have been waiting even longer for big-ticket 3.0 items like > JDK8 and HDFS EC that were part of the discussed scope. > > > Except our schedule is so fluid (not due to the release management process > to be fair) that it is hard for folks to plan their features. IIRC, our > schedule was a GA release beginning of this year. Again, this is not a > critique of 3.0 release process - I have myself done enough releases to > know that sticking to a date and herding the crowd has been an extremely > hard job. > > Schedules have been fluid because we don't know when features are getting in, and there's an unwillingness to bump features to the next release. The goal of the 3.x alphas and betas was to break out of this release anti-pattern, and release on a schedule. There have been schedule delays during the 3.x alphas, but I'm still proud that we released 4 alphas in 10 months. I'm doing my best to stick to our published schedule, and add a beta and GA to that list by EOY. Best, Andrew
