<div dir="ltr">+1 to everything Hans said. We should standardize how we reference bugs from commits, and then get better about tagging the issues in ways that are useful to release managers.<div><div class="gmail_extra"><br></div><div class="gmail_extra">I like the idea of a custom phabricator field, so we can make the references clickable from reviews.</div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, May 2, 2016 at 3:45 PM, Hans Wennborg via llvm-dev <span dir="ltr"><<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Mon, May 2, 2016 at 1:35 PM, Quentin Colombet via llvm-dev<br>
<<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>> wrote:<br>
> I am sending this proposal to get feedbacks on how we could make the tagging of bug fixes and regressions more obvious. The idea is to provide easily accessible information to help deciding what to cherry-pick in a release branch.<br>
><br>
> * Context *<br>
><br>
> People shipping compilers based on LLVM may not completely align with the official releases of LLVM. Thus, the stabilization of each custom release may happen at different period of time. Because of that, release managers have to come up with their own strategy to decide which commits should be cherry-picked during the stabilization of their release branch.<br>
<br>
</span>(Unrelated to your proposal, I'm curious how common it is to base<br>
releases of LLVM-based tools off the upstream release branches vs.<br>
other revisions.)<br>
<span class=""><br>
> For the official LLVM releases, people (committers, code owners, etc.) notice LLVM release managers that a given commit is worth pulling into the release. I would like to put in place something more systematic and that plays nicely with scripting and such that would extend this mechanism.<br>
><br>
> * Proposal *<br>
><br>
> 1. Use [Fix] for commit related to bug fixes.<br>
<br>
</span>I think we're mostly pretty good at referencing PR's in commit<br>
messages already. That's also easy to grep for, so maybe that's good<br>
enough?<br>
<span class=""><br>
> 2. Add a description of the problem in the commit message to help answer the following questions:<br>
> - What is fixed?<br>
> - Which targets are impacted?<br>
> - What is required to trigger the bug? (I.e., how often the end users may encounter it.)<br>
> - When was the bug introduced?<br>
<br>
</span>This sounds like the kind of information that should be in a great<br>
commit message anyways.<br>
<br>
But I'm also thinking that maybe we could be better at using our bug<br>
tracker? Whether a bug is a feature request, something that was always<br>
broken, or a regression (and from what version), sounds like a perfect<br>
fit for a bug tracker. Someone doing a release could then query the<br>
Bugzilla to see e.g. what regression bugs were fixed in a certain time<br>
span.<br>
<span class=""><br>
> #1 At the very least, I would like that each bug fix has a tag on the first line of the commit (i.e., what ends up in the subject line of the related email.) Something like [Fix] would do.<br>
> Thanks to that tag, it would be possible to easily filter bug fixes in email and other cherry-picking helper tools, I believe.<br>
<br>
</span>If we really do want to make a guideline about this, I propose we<br>
standardize on suffixing the first line of the commit with (PRnnn).<br>
<br>
Cheers,<br>
Hans<br>
<div class="HOEnZb"><div class="h5">_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
</div></div></blockquote></div><br></div></div></div>