<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>