[Opendnssec-develop] RE: Process for tracking bugs
Sara Dickinson
sara at sinodun.com
Thu Dec 13 13:51:53 UTC 2012
On 11 Dec 2012, at 09:02, Jerry Lundström wrote:
> Hi,
>
> On Tue, Dec 4, 2012 at 4:40 PM, Sara Dickinson <sara at sinodun.com> wrote:
>> https://wiki.opendnssec.org/display/OpenDNSSEC/Bug+tracking+process
>
> Looks good, I just have two comment:
>
> "Resolve - Add a comment to the issue with the svn revision(s) (or
> even better, a fisheye link to the revision)."
>
> This is not be necessary if you tagged the commit correctly, it will
> show up in the JIRA issue if you select All or Source tab (which is
> why we have FishEye after all).
Good point - I will update to say this is only needed if the commit wasn't tagged.
>
> "Resolve - Clearly state what branches have been fixed."
>
> This can be simplified if we start using different issues for
> different branches/versions, for example if a problem might be related
> to 2 or more branches/versions you make an issue about the problem
> then create subtasks / linked issues for each related branch/version.
Another good point. Do we want to change the process to this? It has pros and cons:
+ the issue state will show the different stage of fixes in different branches
+ harder to forget to do branch specific documentation, jenkins tests, etc if there is a dedicated issue for each branch
- more overhead as more issues created
- harder to see what branches a fix affects as you have to pull up at least 2 JIRA issues, rather than just looking at one field
- requires the fixes for different branches to go in different commits for the jira <-> fisheye link to work
- could be confusing since in the NEWS file fixes for the same issue will have different issue numbers in different branches.
On balance I prefer what we do now i.e. one issue for all branches. Anyone else?
Sara.
>
> --
> Jerry Lundström - OpenDNSSEC Developer
> http://www.opendnssec.org/
More information about the Opendnssec-develop
mailing list