db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Rick Hillegas (JIRA)" <j...@apache.org>
Subject [jira] Commented: (DERBY-4857) Utilize the SOAP API to fetch JIRA issue list for release notes generation
Date Wed, 20 Oct 2010 20:22:25 GMT

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

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

Thanks for the patch, Kristian. I have taken a look at it and have a couple preliminary comments
to offer. Unfortunately, I don't know enough about this technology to be able to test-drive
the patch. Here are some things I tried in order to build this patch:

o I changed directory to the root of my client and typed "mvn -Pbuildclient". Nothing happened.
The buildclient target was not recognized.

o I changed directory to maven2 and typed "mvn -Pbuildclient". Again, the buildclient target
was not recognized.

o From the root of my client, I did an "ant clobber" followed by "ant all". This build failed
because ReportParser was not found.

I would like to test-drive the patch. Could you expand the instructions? Think in terms of
writing a cookbook for someone who knows absolutely nothing about SOAP and very little about
maven. For instance, there seem to be some classes which are generated by the SOAP/maven machinery
but I don't know how or when that generation is supposed to happen. Thanks.

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

Here are some preliminary comments on the patch:

o The name Client seems a little vague to me. Could this class be renamed to something which
captures more of its behavior, like JiraFilterReader or FilteredIssueLister? There may be
a small chunk of code in there which could be carved out into a generic Client or SoapClient
or JiraSoapClient class, but most of the work seems focused on reading a Jira filter and writing
a list of issues.

o If I understand the code correctly, the logic in Client.getAncestors() is trying to construct
the upgrade trajectory which will be used to calculate the set of issues to include in the
release notes. Most of the work is done in Client.getReleasedVersions(). Most of the time,
I think that this logic will do the right thing. However, its concept of ancestor differs
somewhat from the concept of ancestor which is assumed by our release notes process. That
concept is discussed in this email thread: http://old.nabble.com/Release-Notes-to5931299.html#a6248974
Here's how I think the concepts differ:

a) For Client.getAncestors(), released distribution A is an ancestor of release candidate
B if (A.releaseID < B.releaseID).

b) Given the discussion in the email thread referenced above, ancestry should be recursively
defined by the precedingRelease function. If C is a release, then precedingRelease( C ) is
the "preceding release" mentioned at the beginning of the release notes for C. The ancestry
set of candidate B is { precedingRelease(B), precedingRelease(precedingRelease(B)), ...}.
In this scheme, released distribution A is an ancestor of release candidate B if A is in that
ancestry set.

Definition (a) yields a larger set of ancestors than definition (b) does. I believe that the
logic in (a) will overaggressively filter issues. Here is the problem case:

i) We release 10.6.2.1.

ii) Then we release 10.7.1.0.

iii) Then we fix bug NNNN in both the 10.6 and 10.7 branches.

iv) Then we release 10.6.3.0, including the fix for NNNN.

v) Then we release 10.7.2.0, also including the fix for NNNN. Note that precedingRelease(
10.7.2.0 ) = 10.7.1.0 NOT 10.6.3.0.

vi) The fix for NNNN will not appear in the release notes for 10.7.2.0 under definition (a).
However, the fix will appear in the release notes for 10.7.2.0 under definition (b).

Unfortunately, I don't think that Jira contains enough information to calculate release ancestry
under definition (b). I think that the information can be reconstructed by parsing the release
notes in our subversion tags. Alternatively, we could maintain the ancestry graph in the codeline.

What you have so far is a big improvement over the current situation. I think it would be
OK to fix getAncestors() later on.


> 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.0.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.


Mime
View raw message