<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body>
<div dir="ltr">Hey everyone!
<div><br>
</div>
<div>Over the past few months there's been an increase in the number of patches without bug reports, and a decrease in the number of backports. I wanted to take a moment to explain why bug reports are useful, not just bureaucracy, and how they link to backports.</div>
<div><br>
</div>
<div>Bug reports help in a few ways:</div>
<div>- They can contain logs, images and discussion about the nature of a bug that helps reviewers do their job faster. This kind of verbosity is ideal for a bug report, but not suited to a commit message. Generally, the bug report should provide information
 about the *problem*, while the commit message provides information about the *solution*.</div>
<div>- For most people, bug reports are much easier to search than parsing git logs. Remember that not everyone is a git wizard.</div>
<div>- The tagging system allows us to mark things for backporting, with tags like "ocata-backport-potential". The tag system is currently how I manage most of our backports.</div>
<div>- Bugs that have been correctly closed (i.e. "Fix Released") and targeted to a milestone (i.e. "Pike-3") provide helpful metrics for how the project is progressing.</div>
<div><br>
</div>
<div>In most cases, a bug is *required* on a patch. If the patch is extremely small and self-explanatory - things like whitespace cleanup and typos - then we have no need to hold them up. Aside from that, I expect cores to please ask for bug reports to be added,
 and where necessary, target them to a milestone and add tags for service knowledge, backporting etc. Otherwise, I have to manually go through all of the recent merged changes looking for eligible backports, rather than just clicking the "ocata-backport-potential"
 tag.</div>
<div><br>
</div>
<div>Thanks,</div>
<div>Rob</div>
</div>
</body>
</html>