hadoop-hdfs-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrew Wang <andrew.w...@cloudera.com>
Subject Re: IMPORTANT: automatic changelog creation
Date Thu, 02 Jul 2015 21:01:05 GMT
Hi all,

I want to revive the discussion on this thread, since the overhead of
CHANGES.txt came up again in the context of backporting fixes for
maintenance releases.

Allen's automatic generation script (HADOOP-11731) went into trunk but not
branch-2, so we're still maintaining CHANGES.txt everywhere. What do people
think about backporting this to branch-2 and then removing CHANGES.txt from
trunk/branch-2 (HADOOP-11792)? Based on discussion on this thread and in
HADOOP-11731, we seem to agree that CHANGES.txt is an unreliable source of
information, and JIRA is at least as reliable and probably much more so.
Thus I don't see any downsides to backporting it.

Would like to hear everyone's thoughts on this, I'm willing to drive the


On Thu, Apr 2, 2015 at 2:00 PM, Tsz Wo Sze <szetszwo@yahoo.com.invalid>

> Generating change log from JIRA is a good idea.  It bases on an assumption
> that each JIRA has an accurate summary (a.k.a. JIRA title) to reflect the
> committed change. Unfortunately, the assumption is invalid for many cases
> since we never enforce that the JIRA summary must be the same as the change
> log.  We may compare the current CHANGES.txt with the generated change
> log.  I beg the diff is long.
> Besides, after a release R1 is out, someone may (accidentally or
> intentionally) modify the JIRA summary.  Then, the entry for the same item
> in a later release R2 could be different from the one in R1.
> I agree that manually editing CHANGES.txt is not a perfect solution.
> However, it works well in the past for many releases.  I suggest we keep
> the current dev workflow.  Try using the new script provided by
> HADOOP-11731 to generate the next release.  If everything works well, we
> shell remove CHANGES.txt and revise the dev workflow.  What do you think?
> Regards,Tsz-Wo
>      On Thursday, April 2, 2015 12:57 PM, Allen Wittenauer <
> aw@altiscale.com> wrote:
> On Apr 2, 2015, at 12:40 PM, Vinod Kumar Vavilapalli <
> vinodkv@hortonworks.com> wrote:
> >
> > We'd then doing two commits for every patch. Let's simply not remove
> CHANGES.txt from trunk, keep the existing dev workflow, but doc the release
> process to remove CHANGES.txt in trunk at the time of a release going out
> of trunk.
> Might as well copy branch-2’s changes.txt into trunk then. (or 2.7’s.
> Last I looked, people updated branch-2 and not 2.7’s or vice versa for some
> patches that went into both branches.)  So that folks who are committing to
> both branches and want to cherry pick all changes can.
> I mean, trunk’s is very very very wrong. Right now. Today. Borderline
> useless. See HADOOP-11718 (which I will now close out as won’t fix)… and
> that jira is only what is miscategorized, not what is missing.

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