Thanks Sunil for volunteering to lead the release effort. I am generally
supportive of a release but -1 on a 3.2 (prefer a 3.1.x) as feel we already
have too many branches to be maintained. I already see many commits are in
different branches with no apparent rationale, for e.g: 3.1 has commits
which are absent in 3.0 etc.

Additionally AFAIK 3.x has not been deployed in any major production
setting so the cost of adding features should be minimal.

Thoughts?

-Subru

On Thu, Jul 19, 2018 at 12:31 AM, Sunil G <sun...@apache.org> wrote:

> Thanks Steve, Aaron, Wangda for sharing thoughts.
>
> Yes, important changes and features are much needed, hence we will be
> keeping the door open for them as possible. Also considering few more
> offline requests from other folks, I think extending the timeframe by
> couple of weeks makes sense (including a second RC buffer) and this should
> ideally help us to ship this by September itself.
>
> Revised dates (I will be updating same in Roadmap wiki as well)
>
> - Feature freeze date : all features to merge by August 21, 2018.
>
> - Code freeze date : blockers/critical only, no improvements and non
> blocker/critical
>
> bug-fixes  August 31, 2018.
>
> - Release date: September 15, 2018
>
> Thank Eric and Zian, I think Wangda has already answered your questions.
>
> Thanks
> Sunil
>
>
> On Thu, Jul 19, 2018 at 12:13 PM Wangda Tan <wheele...@gmail.com> wrote:
>
> > Thanks Sunil for volunteering to be RM of 3.2 release, +1 for that.
> >
> > To concerns from Steve,
> >
> > It is a good idea to keep the door open to get important changes /
> > features in before cutoff. I would prefer to keep the proposed release
> date
> > to make sure things can happen earlier instead of last minute and we all
> > know that releases are always get delayed :). I'm also fine if we want
> get
> > another several weeks time.
> >
> > Regarding of 3.3 release, I would suggest doing that before thanksgiving.
> > Do you think is it good or too early / late?
> >
> > Eric,
> >
> > The YARN-8220 will be replaced by YARN-8135, if YARN-8135 can get merged
> > in time, we probably not need the YARN-8220.
> >
> > Sunil,
> >
> > Could u update https://cwiki.apache.org/confluence/display/HADOOP/
> Roadmap
> > with proposed plan as well? We can fill feature list first before getting
> > consensus of time.
> >
> > Thanks,
> > Wangda
> >
> > On Wed, Jul 18, 2018 at 6:20 PM Aaron Fabbri <fab...@cloudera.com.invalid
> >
> > wrote:
> >
> >> On Tue, Jul 17, 2018 at 7:21 PM Steve Loughran <ste...@hortonworks.com>
> >> wrote:
> >>
> >> >
> >> >
> >> > On 16 Jul 2018, at 23:45, Sunil G <sun...@apache.org<mailto:
> >> > sun...@apache.org>> wrote:
> >> >
> >> > I would also would like to take this opportunity to come up with a
> >> detailed
> >> > plan.
> >> >
> >> > - Feature freeze date : all features should be merged by August 10,
> >> 2018.
> >> >
> >> >
> >> >
> >> > <snip>
> >>
> >> >
> >> > Please let me know if I missed any features targeted to 3.2 per this
> >> >
> >> >
> >> > Well there these big todo lists for S3 & S3Guard.
> >> >
> >> > https://issues.apache.org/jira/browse/HADOOP-15226
> >> > https://issues.apache.org/jira/browse/HADOOP-15220
> >> >
> >> >
> >> > There's a bigger bit of work coming on for Azure Datalake Gen 2
> >> > https://issues.apache.org/jira/browse/HADOOP-15407
> >> >
> >> > I don't think this is quite ready yet, I've been doing work on it, but
> >> if
> >> > we have a 3 week deadline, I'm going to expect some timely reviews on
> >> > https://issues.apache.org/jira/browse/HADOOP-15546
> >> >
> >> > I've uprated that to a blocker feature; will review the S3 & S3Guard
> >> JIRAs
> >> > to see which of those are blocking. Then there are some pressing
> "guave,
> >> > java 9 prep"
> >> >
> >> >
> >>  I can help with this part if you like.
> >>
> >>
> >>
> >> >
> >> >
> >> >
> >> > timeline. I would like to volunteer myself as release manager of 3.2.0
> >> > release.
> >> >
> >> >
> >> > well volunteered!
> >> >
> >> >
> >> >
> >> Yes, thank you for stepping up.
> >>
> >>
> >> >
> >> > I think this raises a good q: what timetable should we have for the
> >> 3.2. &
> >> > 3.3 releases; if we do want a faster cadence, then having the outline
> >> time
> >> > from the 3.2 to the 3.3 release means that there's less concern about
> >> > things not making the 3.2 dealine
> >> >
> >> > -Steve
> >> >
> >> >
> >> Good idea to mitigate the short deadline.
> >>
> >> -AF
> >>
> >
>

Reply via email to