Myrna van Lunteren wrote:
Hi,
I looked at the Release Notes-per version option of JIRA as well as
the <trunk>/RELEASE-NOTES.html generated by Rick's release notes
generator (see DERBY-2570) and I notice that many bugs are listed that
were already fixed in 10.2.2.0.
JIRA allows us to add many versions in the 'Fixed-In' field.
In the past, we have indeed done this, and if a fix was backported
from a later version (e.g. from trunk at 10.3 to 10.2 branch before
10.2.2.0) we just add the older release to the newer.
Unfortunately, as far as I can see, there's no way in JIRA to set up a
search filter so that you can find the bugs that were fixed in
10.3.0.0, and were not also fixed in 10.2.2.0.
So, creating release notes for 10.3.0.0 with changes not in 10.2.2.0
has become quite complicated.
I would like to go back and modify the fixed-in field for all bugs
that were fixed in or before 10.2.2.0 to *not* list 10.3.0.0. And I
think that should become the rule in the future too, so that only 1
released version should appear for 'fixed-in' for most bugs. (There
are a few that were backported after the latest release on an older
branch - those would still have multiple fix-versions).
Does anyone see a problem with this?
The Jira fix-in field should reflect reality, which I think it currently
does. That is it reflects the branches/trunk the bug was fixed in and
their versions at the time of the fix. If a bug is changed to 10.2.2.0
only, then how does one tell if it has been fixed in trunk? Just stating
it should be fixed in trunk if it was fixed in a branch is not
sufficient, this is open source, if a contributor/committer only wants
to fix a bug in a branch then that's fine, there's no requirement to
also fix it in trunk. Ideally it should be done, but someone has to
volunteer to do the work.
I see Jira as the raw data, it's up to the release notes process to
produce useful human readable information from it.
Dan.
