db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel John Debrunner <...@apache.org>
Subject Re: 10.3 fixed bugs /JIRA fix-in field...
Date Tue, 22 May 2007 20:18:04 GMT
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.


Mime
View raw message