hadoop-yarn-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sangjin Lee <sj...@apache.org>
Subject Re: continuing releases on Apache Hadoop 2.6.x
Date Wed, 25 Nov 2015 18:55:13 GMT
If the speed and clarity are important for the security release, then I
would argue for a single-fix release (2.6.2 + HADOOP-12577 only). The
verification of the RC and the associated release process would be so much
faster.

We would need to do a little bit of special branch creation etc., but it
would still be very straightforward. My 2 cents.

Sangjin

On Wed, Nov 25, 2015 at 10:23 AM, Junping Du <jdu@hortonworks.com> wrote:

> Given there is a critical security fix (HADOOP-12577) coming, I think we
> should move faster on releasing 2.6.3.
> I would propose to freeze nominating new fixes to 2.6.3 unless they are
> critical enough as blocker. We can nominate more fixes later in 2.6.4.
> Thoughts?
>
> Thanks,
>
> Junping
> ________________________________________
> From: sjlee0@gmail.com <sjlee0@gmail.com> on behalf of Sangjin Lee <
> sjlee@apache.org>
> Sent: Friday, November 20, 2015 7:07 PM
> To: mapreduce-dev@hadoop.apache.org
> Cc: Hadoop Common; yarn-dev@hadoop.apache.org; hdfs-dev@hadoop.apache.org
> Subject: Re: continuing releases on Apache Hadoop 2.6.x
>
> It would be great if we can get enough number of fixes by early December.
> 18 seems bit on the low side, but if we lose this window it won't be until
> next year.
>
> As for the release management, thanks Chris, Junping, and Haohui for
> volunteering! I'll reach out to you to discuss what we do with 2.6.3. I
> assume we will have more maintenance releases in the 2.6.x line, so there
> will be more opportunities. We do need one person with PMC privileges to be
> able to go through all the release management steps without assistance,
> which I learned last time.
>
> Regards,
> Sangjin
>
> On Fri, Nov 20, 2015 at 10:03 AM, Sean Busbey <busbey@cloudera.com> wrote:
>
> > Early december would be great, presuming the RC process doesn't take too
> > long. By then it'll already have over a month since the 2.6.2 release and
> > I'm sure the folks contributing the 18 patches we already have in would
> > like to see their work out there.
> >
> > On Fri, Nov 20, 2015 at 7:51 AM, Junping Du <jdu@hortonworks.com> wrote:
> >
> > > +1. Early Dec sounds too early for 2.6.3 release given we only have 18
> > > patches since recently release 2.6.2.
> > > We should nominate more fixes and wait a while for the feedback on
> 2.6.2.
> > >
> > > Thanks,
> > >
> > > Junping
> > > ________________________________________
> > > From: Vinod Vavilapalli <vinodkv@hortonworks.com>
> > > Sent: Thursday, November 19, 2015 11:34 PM
> > > To: yarn-dev@hadoop.apache.org
> > > Cc: common-dev@hadoop.apache.org; hdfs-dev@hadoop.apache.org;
> > > mapreduce-dev@hadoop.apache.org
> > > Subject: Re: continuing releases on Apache Hadoop 2.6.x
> > >
> > > I see 18 JIRAs across the sub-projects as of now in 2.6.3. Seems like
> we
> > > will have a reasonable number of fixes if we start an RC early
> december.
> > >
> > > In the mean while, we should also review 2.7.3 and 2.8.0 blocker /
> > > critical list and see if it makes sense to backport any of those into
> > 2.6.3.
> > >
> > > +Vinod
> > >
> > >
> > > On Nov 17, 2015, at 5:10 PM, Sangjin Lee <sjlee@apache.org<mailto:
> > > sjlee@apache.org>> wrote:
> > >
> > > I'd like to pick up this email discussion again. It is time that we
> > started
> > > thinking about the next release in the 2.6.x line. IMO we want to walk
> > the
> > > balance between maintaining a reasonable release cadence and getting a
> > good
> > > amount of high-quality fixes. The timeframe is a little tricky as the
> > > holidays are approaching. If we have enough fixes accumulated in
> > > branch-2.6, some time early December might be a good target for cutting
> > the
> > > first release candidate. Once we miss that window, I think we are
> looking
> > > at next January. I'd like to hear your thoughts on this.
> > >
> > >
> >
> >
> > --
> > Sean
> >
>

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