Mailing-List: contact hdfs-dev-help@hadoop.apache.org; run by ezmlm
Precedence: bulk
MIME-Version: 1.0
In-Reply-To: <CAGB5D2ZiH811Q3QmiATgkDZvY=Mnt7ohjs-uUKe5yQ427PNMfQ@mail.gmail.com>
References: <CAGB5D2bhj+4m7yaPY7wq2UvC5XrJDRpqKDV+AA9aamqCtb08ig@mail.gmail.com>
 <9B21996B-4753-4BB4-A28D-90F62E4A5FC0@apache.org> <DB0D97BC-8285-49A7-91D8-77DFD1310951@hortonworks.com>
 <3C5A14F9-052F-4DDD-A460-9B7849F0E40C@apache.org> <EB8471B2-55AB-419D-BA62-1055DA093F7D@hortonworks.com>
 <3c78cc0f-e2a6-0325-2462-a8d143b07287@apache.org> <CB7A68E8-88D3-4F20-8EB7-9375C8585D2E@apache.org>
 <CAE=b_fYMQBaFBAG7++vX2L1ZimAiaqpvYMbx+DnJDAGe_kwhCw@mail.gmail.com>
 <CAMs9kVhbCs0Cmb6iX10tjyasEcC=HEiTMhfuJpmJ2D76it8iNw@mail.gmail.com>
 <CAGB5D2aOPkB2AoVTif-ZMxR959euqqFWi-pKwC_0x+OmBefVcg@mail.gmail.com>
 <06B37CAC-4D65-4209-ACB2-987EE5275D6A@apache.org> <CAGB5D2ZiH811Q3QmiATgkDZvY=Mnt7ohjs-uUKe5yQ427PNMfQ@mail.gmail.com>
From: Vrushali C <vrushalic2016@gmail.com>
Date: Tue, 29 Aug 2017 15:21:59 -0700
Message-ID: <CAE=b_faD4qvE9bumVBBSzSCdOsENaB4dpsW5sutU2jd-K5ghGw@mail.gmail.com>
Subject: Re: Branch merges and 3.0.0-beta1 scope
To: Andrew Wang <andrew.wang@cloudera.com>
Cc: Vinod Kumar Vavilapalli <vinodkv@apache.org>, Ravi Prakash <ravihadoop@gmail.com>,
	Ray Chiang <rchiang@apache.org>, Steve Loughran <stevel@hortonworks.com>,
	"common-dev@hadoop.apache.org" <common-dev@hadoop.apache.org>,
	"hdfs-dev@hadoop.apache.org" <hdfs-dev@hadoop.apache.org>,
	"mapreduce-dev@hadoop.apache.org" <mapreduce-dev@hadoop.apache.org>,
	"yarn-dev@hadoop.apache.org" <yarn-dev@hadoop.apache.org>
Content-Type: multipart/alternative; boundary="001a114606040bd8e20557ebd701"
archived-at: Tue, 29 Aug 2017 22:24:08 -0000

--001a114606040bd8e20557ebd701
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

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.wang@cloudera.com>
wrote:

> 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 dat=
e.
>> A typical software development lifecycle includes weeks of feature freez=
e
>> 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 =E2=80=98typical' lifecycle that I am guessin=
g 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 s=
o
>> 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 alpha=
4
> as feature complete and beta1 as code complete so we could quickly move o=
n
> to GA.
>
>
>> What we do with Apache releases typically is instead we say =E2=80=98thi=
s' 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 whe=
n
> 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 w=
as
>> 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 lik=
e
>> 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. II=
RC,
>> 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. Th=
e
> 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 prou=
d
> 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
>

--001a114606040bd8e20557ebd701--