[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