hadoop-common-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Karthik Kambatla <ka...@cloudera.com>
Subject Re: auto-generating changes.txt was: migrating private branches to the new git repo
Date Fri, 05 Sep 2014 16:19:22 GMT
On Thu, Sep 4, 2014 at 8:37 AM, Allen Wittenauer <aw@altiscale.com> wrote:

>
>         I hacked on it some more and yes, it’s very easy to detect:
>
> * type of jira (improvement, bug, new feature, wish, task, sub-task)
> * incompatible or not (regardless of type)
> * reviewed or not (regardless of type)
>
>         A key question is what to do about tasks, sub-tasks, and wishes.
> I haven’t tried yet, but I’m fairly confident that sub-tasks list what the
> parent is, so those can probably be handled specially.  We either need to
> list tasks and wishes as what they are or, in the script, turn them into
> something else.
>
>         Also added some sorting to it based upon number.  I’m not sure
> what order we’re getting from JIRA now.  Last updated time is going to be
> wonky with all the changes I did.  I didn’t look to see if there was a
> ‘resolve date’.
>
>         It should be noted that the release note script already created
> different files: a master one and one for each project.  That functionality
> was kept but I just shared the master one because it was easier. ;)
>
>
> https://github.com/aw-altiscale/hadoop/blob/trunk/dev-support/changes.py
> is the current version if someone wants to look at it.
>
>         We do need to have a talk about 3.x though.  Looking over the
> list, it would appear that a lot of (what became) early 2.x JIRAs were
> marked as Fixed against 3.x.  Probably 2/3’rd of the JIRAs showing up!  I
> think it may be safe to just say “everything before date X should be set to
> 2.x”, but I’m not sure of what that date would be.  Doing that would chop
> the 3.x change list down to a much more realistic size, esp when compared
> to the manual changes file.
>

Would it help to look at the git commits for a release, and fetch the
corresponding details from JIRA for those commits that have a JIRA #?


>
> On Sep 4, 2014, at 4:38 AM, Steve Loughran <stevel@hortonworks.com> wrote:
>
> > is there any way of isolating compatible/incompatible changes, & new
> > features?
> >
> > I know that any change is potentially incompatible —but it is still good
> to
> > highlight the things we know are likely to cause trouble
> >
> >
> > On 4 September 2014 02:51, Allen Wittenauer <aw@altiscale.com> wrote:
> >
> >> Nothing official or clean or whatever, but just to give people an idea
> of
> >> what an auto generated CHANGES.txt file might look like, here are some
> >> sample runs of the hacky thing I built, based upon the fixVersion
> >> information.  It doesn't break it down by improvement, etc.  Also, the
> name
> >> on the end is the person who the JIRA is assigned.  If it is unassigned,
> >> then it comes out blank.  It's interesting to note that in the 2.5.1
> notes,
> >> it does appear to have caught a commit missing from the changes.txt….
> >>
> >> 2.5.1: http://pastebin.com/jXfz5wXz
> >>
> >> 2.6.0: http://pastebin.com/5nkSsU18
> >>
> >> 3.0.0: http://pastebin.com/3Ek4tP8d
> >>
> >> One thing I didn't do was append the previous versions onto these files,
> >> which is what I'd expect to happen.
> >
> > --
> > CONFIDENTIALITY NOTICE
> > NOTICE: This message is intended for the use of the individual or entity
> to
> > which it is addressed and may contain information that is confidential,
> > privileged and exempt from disclosure under applicable law. If the reader
> > of this message is not the intended recipient, you are hereby notified
> that
> > any printing, copying, dissemination, distribution, disclosure or
> > forwarding of this communication is strictly prohibited. If you have
> > received this communication in error, please contact the sender
> immediately
> > and delete it from your system. Thank You.
>
>

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