[llvm-dev] [RFC] Helping release management

[Smith, Kevin B via llvm-dev]

>-----Original Message-----
>From: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] On Behalf Of
>Quentin Colombet via llvm-dev
>Sent: Monday, May 02, 2016 1:35 PM
>To: llvm-dev <llvm-dev at lists.llvm.org>
>Subject: [llvm-dev] [RFC] Helping release management
>
>Hi,
>
>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.
>

This seems like a great idea to me.

>* Proposal *
>
>1. Use [Fix] for commit related to bug fixes.

a specific form would be best: [Fix] PR12345, or [FIX] Bug introduced in r56789.

>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 is super important for things that regress, and then get fixed before a PR is even filed.  Even for a PR if the problem was introduced in a known
revision, having that in the commit message helps to understand whether some other revision is really safe to pull into a release.

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

I like it.

>
>Thanks,
>-Quentin
>_______________________________________________
>LLVM Developers mailing list
>llvm-dev at lists.llvm.org
>http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev