hadoop-mapreduce-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Vrushali C <vrushalic2...@gmail.com>
Subject Re: Branch merges and 3.0.0-beta1 scope
Date Tue, 29 Aug 2017 22:21:59 GMT
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.


On Tue, Aug 29, 2017 at 2:25 PM, Andrew Wang <andrew.wang@cloudera.com>

> Hi Vinod,
> On Fri, Aug 25, 2017 at 2:42 PM, Vinod Kumar Vavilapalli <
> vinodkv@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

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message