[llvm-dev] [RFC] Helping release management

[Mehdi Amini via llvm-dev]

> On May 2, 2016, at 2:05 PM, Smith, Kevin B via llvm-dev <llvm-dev at lists.llvm.org> wrote:
> 
> 
> 
>> -----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.

The first line of the commit is interpreted as a "title" by "git based" tools. 
I rather have a self-contained first line and avoid *any* external reference there.
(The commit message can be as long as you want).

-- 
Mehdi




> 
>> 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
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev