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