Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: <derby-dev@db.apache.org>
Message-ID: <10803601.31691287774257277.JavaMail.jira@thor>
Date: Fri, 22 Oct 2010 15:04:17 -0400 (EDT)
From: "Rick Hillegas (JIRA)" <jira@apache.org>
To: derby-dev@db.apache.org
Subject: [jira] Commented: (DERBY-4857) Utilize the SOAP API to fetch JIRA
 issue list for release notes generation
In-Reply-To: <2044107.8841287582326586.JavaMail.jira@thor>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ https://issues.apache.org/jira/browse/DERBY-4857?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12923971#action_12923971 ] 

Rick Hillegas commented on DERBY-4857:
--------------------------------------

Thanks again for the patch, Kristian. I updated my client, which got me past the build issues. After that, I was able to test-drive the patch and successfully build the release notes. Love it. A couple comments:

o It would be nice if the tool had a quiet mode. Maven is pretty chatty and yours truly doesn't need to see the list of excluded bugs.

o Maven coughs up the following warning. It didn't seem to hurt anything but I'm probably not the only person who will be puzzled by it:

    WARNING: Unable to find required classes (javax.activation.DataHandler and javax.mail.internet.MimeMultipart). Attachment support is disabled.

o I had to remove the following sanity-check from ReleaseNotesGenerator (line 282). It will kill release notes generation for feature releases. That is because the release manager wants to publish the release notes a good week before creating the branch and building the first release candidate. At that time, the version number in release.properties is still an alpha version number. I tripped across the fact that the version number in release.properties on the trunk was 10.7.0.0 but I was trying to generate release notes for 10.7.1.0:

 else if (!relVer.equals(releaseID)) {
            throw new IllegalStateException("target release version mismatch " +
                    "between release.properties and bug list: " + releaseID +
                    " != " + relVer);
        }

I think that the release number which appears in RELEASE-NOTES.html should originate with the release number which you specify when you run "java -jar target/JiraSOAP-LATEST-jar-with-dependencies.jar".

At this point, you have removed one of the redundant places where we specify the release number (namely, in releaseSummary.xml). That's progress. I don't think we need to sand this down further, although it's worth thinking about streamlining how many times we still specify a release id:

o We specify a release id when we define the jira filter which defines the raw stream of bug ids.

o We specify a release id when we run "java -jar target/JiraSOAP-LATEST-jar-with-dependencies.jar".

o We specify a release id when we run the master target which builds the release candidate.

Here is the script which I used to tie together all of the pieces of release-notes generation. This may be useful to other release managers who want to test-drive this patch:

Thanks,
-Rick

----------------

#! /bin/bash
#
# Run the machinery which creates the release notes. Make sure
# that you are not on a corporate VPN--otherwise maven may hang
# while trying to access the network.
#
# Arguments:
#
# $1  jira user name
# $2  jira password
# $3  release version (e.g. 10.7.1.0)
# $4  numeric id of filter used to create jira report of fixed bugs (e.g. 12314683)
#
# E.g.:
#
#   createReleaseNotes rhillegas mypassword 10.7.1.0 12314683


export jiraname=$1
export jirapassword=$2
export derbyversion=$3

export relnotesdir=$HOME/junk/$derbyversion-relnotes

export filterid=$4
export destinationfile=$relnotesdir/fixedBugsList.txt
export remove=true

mkdir $relnotesdir

cd $BRANCH/tools/release/jirasoap

# build the application which uses SOAP to tease information out of JIRA

mvn -Pbuildclient

# now produce the filtered list of issues

java -jar target/JiraSOAP-LATEST-jar-with-dependencies.jar $jiraname $jirapassword $derbyversion $filterid $destinationfile $remove

# now generate RELEASE-NOTES.html from the filtered list

cd ..

ant -Drelnotes.src.reports=$relnotesdir genrelnotes


> Utilize the SOAP API to fetch JIRA issue list for release notes generation
> --------------------------------------------------------------------------
>
>                 Key: DERBY-4857
>                 URL: https://issues.apache.org/jira/browse/DERBY-4857
>             Project: Derby
>          Issue Type: Improvement
>          Components: Build tools
>    Affects Versions: 10.7.1.0
>            Reporter: Kristian Waagan
>            Assignee: Kristian Waagan
>         Attachments: derby-4857-1a-jirasoap_relnotes.diff, derby-4857-1a-jirasoap_relnotes.stat
>
>
> Somewhat simplified, the release manager (RM) must currently perform the following manual steps to feed the release note generate the data it needs:
>  a) Create manual JIRA filter to select issues addressed by the release.
>  b) Save the filter result to disk as XML.
>  c) Write/modify the XML parser to be able to parse the report.
>  d) Determine and record all JIRA release note attachment ids for the issues requiring a release note.
> By using the current version of the SOAP API (3.13.5), steps (b) to (d) can be removed.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.