> On Jan 3, 2015, at 12:03 PM, Leif Hedstrom <[email protected]> wrote: > > Hi all, > > James and I had some discussions around how to best manage Jira’s and > Coverity static analysis fixes. One suggestion is the following (but please > discuss):
If you mark a Coverity issue as "ignore" or "intentional" and it's not obvious, please explain the rationale in the comments. > > > 1. We create one Jira for every minor / major release. So, e.g. “Coverity for > v5.3.0” would be the next Jira. > > 2. We commit most Coverity fixes against the currently active Jira (but see > #3 below). This Jira gets closed when the next release branch is created, and > a new one is created. Creating and closing these Jira’s is the task of the > release manager(s). > > 3. For serious fixes such as crashes, at the discretion of the contributor, > file a separate Jira for that issue, and commit and close as normal. This sounds reasonable to me. > > > The reason for #3 is that managing back ports without a dedicated Jira > becomes quite problematic. And of course, once we get to “zero bugs” in the > coverity report, we’ll treat new errors as fatal, and put the master branch > in a non-releasable state. At that point, no Coverity Jira’s would be > necessary. > > Thoughts? > > — leif >
