Mailing-List: contact hdfs-dev-help@hadoop.apache.org; run by ezmlm
Precedence: bulk
Reply-To: hdfs-dev@hadoop.apache.org
MIME-Version: 1.0
In-Reply-To: <1452526300017.11401@hortonworks.com>
References: 
 <CAGB5D2ZKX28Wprp9mAVc_+7Ar4mDMgGZEAbSA5XLyJU=DTGfyQ@mail.gmail.com>
 <1452526300017.11401@hortonworks.com>
From: Andrew Wang <andrew.wang@cloudera.com>
Date: Mon, 11 Jan 2016 14:41:34 -0800
Message-ID: 
 <CAGB5D2b1g-tmZrPT22BMQ4ft69PCbJ7jzoV6qT9pV8i0abyeag@mail.gmail.com>
Subject: Re: [VOTE] Release Apache Hadoop 2.7.2 RC1
To: "hdfs-dev@hadoop.apache.org" <hdfs-dev@hadoop.apache.org>
Content-Type: multipart/alternative; boundary=001a114e430cc0c896052916a4b2

--001a114e430cc0c896052916a4b2
Content-Type: text/plain; charset=UTF-8

On Mon, Jan 11, 2016 at 7:22 AM, Junping Du <jdu@hortonworks.com> wrote:

> bq.  Is it difficult to backport to 2.7.x if you're already backporting to
> 2.6.x? I don't follow why special casing some class of fixes is desirable.
> It is not difficult to backport the commits between 2.6.x and 2.7.x.
> However, it do *difficult* to track exactly for hundreds of commits between
> them. Taking HDFS-9470 as an example, the committer totally forget to merge
> the commit into 2.7.2 when it is resolved as fixed in 2.7.2. The commit was
> merged into 2.6.3 later but get missed on 2.7.2 RC1. If this is not a
> critical fix, I don't think 2.7.2 should get a new RC to wait this commit
> to land on. That's why classifying on priority of fixes are important and
> desirable when we are facing this situation.
>
> Gotcha, so this in this case it is the exception and not the rule? I'd
still rather the rule be simple, and then exceptions like this addressed on
a case-by-case basis.

Colin also wrote a branch-diff tool that looks at git log, which makes
tracking easier. You can do things like diff 2.6.0 with 2.6.3, 2.7.0 with
2.7.2, and then make sure that the 2.7 diff is a superset of 2.6.

https://github.com/cmccabe/cmccabe-hbin/blob/master/jirafun.go

Wouldn't be the worst idea to make this part of our release validation
process. The report could be automated as a Jenkins job.


> bq. Also for maintenance releases, aren't all included fixes supposed to
> be for serious bugs? Minor JIRAs can wait for the next minor release. If
> there are strong reasons to include a minor JIRA in a maintenance release,
> then maybe it's not really a minor JIRA.
> If a committer commit a major/minor priority patch on a maintenance
> release, what RM should do? Revert it or upgrade the priority to critical
> even it doesn't belong to critical?
> I believe only commit critical/blocker patch to maintenance release can
> only be a general guideline for maintenance release, but not a strict rule
> for all committers in practice. RMs should obey this guideline strictly in
> cherry-pick commits but there are more commits get committed by other
> committers. The committer choose the fixed branch not only by priority but
> also by target branch proposed by patch contributor who may only work on
> that branch release for a long time. I think this target/fix branch
> negotiation mechanism going on well and we shouldn't break it.
>
> This sounds like another reminder for everyone to:

- Please be judicious about what gets backported to maintenance releases.
- When backporting, please backport to all intermediate maintenance
branches.

Based on what I've seen, the RMs have been very responsive, so the safest
thing is to ping them about inclusion before backporting. I'd be in favor
of a guideline like "get an RM to +1 before backporting."

Best,
Andrew

--001a114e430cc0c896052916a4b2--