<p dir="ltr">I'm with Hans that we should use bugzilla/phab better. It's far easier to update bugs than format commit messages to conform to free text parseable content. </p>
<p dir="ltr">I don't think we should restrict the commit message more than it is, nor that we should reprimand / block / revert patches because of downstream release processes. I also don't think we should change everyone's process to fit to everyone's else's process. That doesn't scale. </p>
<p dir="ltr">I personally want to see all downstream releases participating on the upstream release process, and all their release managers actively engaged in the public process. Anything else will mean additional cost to us all, and go against the open source nature of the project. </p>
<p dir="ltr">My tuppence. <br>
Renato </p>
<div class="gmail_quote">On 3 May 2016 12:34 a.m., "Hans Wennborg via llvm-dev" <<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>> wrote:<br type="attribution"><blockquote class="quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="quoted-text">On Mon, May 2, 2016 at 4:03 PM, Quentin Colombet <<a href="mailto:qcolombet@apple.com">qcolombet@apple.com</a>> wrote:<br>
>>> 1. Use [Fix] for commit related to bug fixes.<br>
>><br>
>> 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>
><br>
> When a PR is available, that is certainly good enough.<br>
> I do not want to make filling a PR mandatory for each bug we fix though. Having a PR is great, but I can see why we may not want to create one each time we fix something.<br>
<br>
</div>At least for me, if I run into a problem that takes some work to<br>
reduce, debug, etc., I find filing a PR worth it, if nothing else to<br>
keep track of the work for my own sake.<br>
<br>
For bugs which one just stumbles across in the code and which can be<br>
fixed with a quick patch, I agree that filing a bug doesn't make<br>
sense.<br>
<br>
I suspect the kind of fixes that are important for a release branch<br>
are mostly of the former kind, though.<br>
<div class="quoted-text"><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>
>> 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>
><br>
> Sounds great to me.<br>
><br>
> Would that kind of workflow ease your job for tracking what should be pulled into the release branch after you’ve branched?<br>
> What would be the best workflow for such task for you?<br>
<br>
</div>My ideal workflow for discovering commits suitable for merging is when<br>
folks cc me on the commit message, because then I don't have to do any<br>
work :-)<br>
<br>
But besides that, I do rely on the bug tracker quite a lot. It's hard<br>
to keep up with the commits list, but keeping up with filed and fixed<br>
bugs is doable, and a good source of information. It's usually easy to<br>
tell from a PR whether it's serious or not, and most people are good<br>
about indicating what version they used, if it started failing<br>
recently, what target they're using, etc.<br>
<div class="elided-text"><br>
Cheers,<br>
Hans<br>
_______________________________________________<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></blockquote></div>