
<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On May 5, 2016, at 10:08 AM, Reid Kleckner via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" class="">llvm-dev@lists.llvm.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class=""><div class="gmail_extra"><div class="gmail_quote">On Wed, May 4, 2016 at 5:07 PM, Quentin Colombet via llvm-dev <span dir="ltr" class=""><<a href="mailto:llvm-dev@lists.llvm.org" target="_blank" class="">llvm-dev@lists.llvm.org</a>></span> wrote:<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word" class=""><div class="">Typically, what I had in mind was things like typos/thinko, that are bugs, that we notice a few minutes after we made the “main” commit. I do not want we have to file a PR that is going to repeat what we are going to say in the commit message.</div></div></blockquote><div class=""><br class=""></div><div class="">Yeah, I agree, we shouldn't have to file PRs for that kind of stuff. Quick fixes for the build or tests on other platforms obviously fall into this category.</div><div class=""><br class=""></div><div class="">Do release managers have problems keeping track of these kinds of changes in practice, though? You can always cut the branch from some quiescent period on the weekend of night before the cut.</div></div></div></div></div></blockquote><br class=""></div><div>I’ve been doing quite a bit of that lately. The problem is not when you cut the branch, but how you maintain it. For multiple months after you branched, you’re willing to take fixes for miscompiles. So you have to got through every commit and gauge the risk/benefit, see if it applies, if it passes the tests… </div><div><br class=""></div><div>Anything that helps tracking that a particular commit need followup commits to be fully functional would be a win. I think just mentioning the original commit in the followups is a minimum (then you can have tooling to relate the commits), but I don’t see a way to enforce this.</div><div><br class=""></div><div>Ideally every commit message would be very explicit about what the commit is:</div><div> - a compiler crash fix (with a description of the crash trigger)</div><div> - a miscompile fix</div><div> - an optimization to the compiler code</div><div> - an optimization to the generated code</div><div> - a refactoring</div><div>It’s not always easy to distinguish between the first four, and you really want to understand it before cherry-picking in a long living branch.</div><div><br class=""></div><div>Oh, and PRs are nice, but when the commit message is just “Fix PR1234”, it’s still quite some work to figure out what to do with the commit :-)</div><div><br class=""></div><div>Fred</div></body></html>