[Opendnssec-develop] RE: Process for tracking bugs

[Sara Dickinson]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


On 10 Dec 2012, at 10:11, Matthijs Mekking wrote:

> Hi,
> 
> The first part lists stuff that I already (try to) do when working on a
> JIRA issue. So I approve with this.
> 
> The second part is more interesting. I have a hard time to decide
> whether something needs go into JIRA.

Thanks for the feedback Matthijs.

One thing that I think we do need to resolve is the question of where to look to see what has changed since the last release and what is still outstanding (for us and to be able to report to users). Right now when we have team meetings and try to decide if we should do a release we currently only look at JIRA. So if there are other important updates that are only in the NEWS file (or only in svn or on the mailing list) then we don't take them into account. 

So we could look at both but.. if something is only in the NEWS file then I assume it means it is fixed (but I don't know what revision it was fixed in), and I don't know if it has been manually tested / covered in jenkins / documented / etc? All useful stuff which could/should go in a JIRA issue.

What I am suggesting is that if changes the behaviour of OpenDNSSEC or fixes a bug then it should go in the NEWS file (this pretty much happens already). And if it is important enough to go in the NEWS file then it should go in JIRA too. 


> For example, if there is a report
> on the mailing list, should we create a JIRA issue for it? According to
> your text, only if it results in code changes.

I really meant _always_ open an issue if it results in code changes (for the reasons above) but this doesn't mean we shouldn't open issues for other things. I can clarify this in the text. 

> I can see another option:
> Always, even if the report turns out to be an error outside  OpenDNSSEC,
> or a not accepted feature request. This way, we can refer to them when
> similar future reports come in.

I don't know that it is useful to mandate we always open an issue but it seems good practice to track important ones in JIRA. 
Feature requests - I think we should always open an issue so it can be reviewed properly
User errors - don't think a JIRA issue is that helpful.
Common misunderstanding - maybe better to add to the FAQ?

> 
> Also, I sometimes change log levels for log messages, as I feel that the
> daemon is too verbose, or not verbose enough. These are code changes,
> but I don't think a JIRA report is needed for them.

I think a bit of common sense can be used here e.g. if you change the format or text of a common log message that users (or our tests) may grep for then let people know by raising an issue, but the kind of tweaks you mention wouldn't need one. 

Sara.

> 
> Best regards,
>  Matthijs
> 
> 
> 
> On 12/04/2012 04:40 PM, Sara Dickinson wrote:
>> Hi All, 
>> 
>> As a follow up to the team meeting yesterday I have written a first draft of a best practices process for how we should try to use JIRA/svn to track bugs:
>> 
>> https://wiki.opendnssec.org/display/OpenDNSSEC/Bug+tracking+process
>> 
>> Please review this and let me know what you think! I'll make sure to raise it in the next team meeting for discussion too. 
>> 
>> Thanks.
>> 
>> Sara.
>> 
>> _______________________________________________
>> Opendnssec-develop mailing list
>> Opendnssec-develop at lists.opendnssec.org
>> https://lists.opendnssec.org/mailman/listinfo/opendnssec-develop
>> 
> 
> 
> _______________________________________________
> Opendnssec-develop mailing list
> Opendnssec-develop at lists.opendnssec.org
> https://lists.opendnssec.org/mailman/listinfo/opendnssec-develop

-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.18 (Darwin)
Comment: GPGTools - http://gpgtools.org

iQEcBAEBAgAGBQJQxc9RAAoJEAuxXeCvTgIIdk8H/A8fnkSPqgPk3Yal4N3gvvhY
IBhkTUb6pGSGNaqyfDKc5B7FmHwQe62mehffe+MEGPbYCRN/+4YmcRglAdXVWKWW
2no3Ol418kw42fquuZmCCCW6NhfYMptNaA+EPrdH9YcykCHdbBes4+//XQz3wPhU
H5qtHuo1C3RIRnD0xwATey1lsJ4wljbJTv6yh72wIPRdLMx0z1Rqhb3nb0kbGUWJ
Hs1n3glPxLQurmx54WnB5YQoKr8gIH7Zq0zm/IC0dZf8LqzGm7MW0DzcIh72W/bz
qtLIFVTcI/ASQ2t0XNyQIrk+yW2ebXdqQGTNvwn7TnmtkxB3B5eEdNYK9JOc2JA=
=QI05
-----END PGP SIGNATURE-----