[llvm-dev] [RFC] Helping release management

[Hans Wennborg via llvm-dev]

On Mon, May 2, 2016 at 1:35 PM, Quentin Colombet via llvm-dev
<llvm-dev at lists.llvm.org> wrote:
> 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.

(Unrelated to your proposal, I'm curious how common it is to base
releases of LLVM-based tools off the upstream release branches vs.
other revisions.)

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

I think we're mostly pretty good at referencing PR's in commit
messages already. That's also easy to grep for, so maybe that's good
enough?

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

This sounds like the kind of information that should be in a great
commit message anyways.

But I'm also thinking that maybe we could be better at using our bug
tracker? Whether a bug is a feature request, something that was always
broken, or a regression (and from what version), sounds like a perfect
fit for a bug tracker. Someone doing a release could then query the
Bugzilla to see e.g. what regression bugs were fixed in a certain time
span.

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

If we really do want to make a guideline about this, I propose we
standardize on suffixing the first line of the commit with (PRnnn).

Cheers,
Hans