hadoop-hdfs-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Karthik Kambatla <ka...@cloudera.com>
Subject Re: IMPORTANT: automatic changelog creation
Date Fri, 03 Jul 2015 03:02:27 GMT
Huge +1

On Thursday, July 2, 2015, Chris Nauroth <cnauroth@hortonworks.com> wrote:

> +1
>
> Thank you to Allen for the script, and thank you to Andrew for
> volunteering to drive the conversion.
>
> --Chris Nauroth
>
>
>
>
> On 7/2/15, 2:01 PM, "Andrew Wang" <andrew.wang@cloudera.com <javascript:;>>
> wrote:
>
> >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
> >effort.
> >
> >Thanks,
> >Andrew
> >
> >On Thu, Apr 2, 2015 at 2:00 PM, Tsz Wo Sze <szetszwo@yahoo.com.invalid>
> >wrote:
> >
> >> 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 <javascript:;>> wrote:
> >>
> >>
> >>
> >>
> >>
> >> On Apr 2, 2015, at 12:40 PM, Vinod Kumar Vavilapalli <
> >> vinodkv@hortonworks.com <javascript:;>> 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.
> >>
> >>
> >>
> >>
>
>

-- 
Mobile

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