bq. 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.
Yes, I have been thinking about this too. Based on what I have observed, [DISCUSS] is more of a late-stage communication typically just like 8-10 days before the [VOTE] goes out. Most the leads send out [DISCUSS] emails when the feature is extremely close to completion. So it seems to me that there is an inherent hesitation in sending out [DISCUSS] emails when things are not close to completion, so the Release Manager does not hear about these early on. Perhaps we want to add another step like [HEADS-UP] which goes out to at least the Release Manager and known stakeholders or perhaps even the entire dev community well before [DISCUSS]. The [HEADS-UP] could be a very simple note that basically says we are still working on this but we wish to aim for so-and-so release. It could go out as soon as release idea is floated but perhaps no later than 7-8 weeks before planned release date. [HEADS-UP] indicates that despite contributors' best efforts, there exists a possibility that that feature may not finish in time to make it into the release but at least the RM is aware of the intentions and can track these. Perhaps a time frame like the following may be good to follow: [HEADS-UP]: typically at least 2 months before release date or as early as anyone wants to communicate to RM. [DISCUSS]: approx 4-6 weeks before release date [VOTE]: closes before 2 (or 3?) weeks before release date While I do think some timeframes like these should become the norm, we may not want to be too rigidly pedantic as well. It may be a good idea to keep ourselves open to making exceptions on a per case basis. thanks Vrushali On Tue, Aug 29, 2017 at 2:25 PM, Andrew Wang <andrew.w...@cloudera.com> wrote: > 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 >
