hadoop-hdfs-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Devaraj K <deva...@apache.org>
Subject Re: IMPORTANT: automatic changelog creation
Date Fri, 03 Jul 2015 13:31:05 GMT
+1

Thanks Allen and Andrew for your efforts on this.

Thanks
Devaraj

On Fri, Jul 3, 2015 at 11:29 AM, Varun Vasudev <vvasudev@apache.org> wrote:

> +1
>
> Many thanks to Allen and Andrew for driving this.
>
> -Varun
>
>
>
> On 7/3/15, 10:25 AM, "Vinayakumar B" <vinayakumarb@apache.org> wrote:
>
> >+1 for the auto generation.
> >
> >bq. Besides, after a release R1 is out, someone may (accidentally or
> >intentionally) modify the JIRA summary.
> >Is there any possibility that, we can restrict someone from editing the
> >issue in jira once its marked as "closed" after release?
> >
> >Regards,
> >Vinay
> >
> >On Fri, Jul 3, 2015 at 8:32 AM, Karthik Kambatla <kasha@cloudera.com>
> wrote:
> >
> >> 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
> >>
>
>


-- 


Thanks
Devaraj K

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