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.
* Context *
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.
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.
* Proposal *
1. Use [Fix] for commit related to bug fixes.
2. Add a description of the problem in the commit message to help answer the following questions:
- What is fixed?
- Which targets are impacted?
- What is required to trigger the bug? (I.e., how often the end users may encounter it.)
- When was the bug introduced?
#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.
Thanks to that tag, it would be possible to easily filter bug fixes in email and other cherry-picking helper tools, I believe.
#2 Although it may be difficult to come up with that information, I believe it should be provided as the best of the committer knowledge. Indeed, this kind of information is useful to help release managers to ascertain how relevant is a change for their release and thus help them to decide whether to cherry-pick this change or not.
What do people think?