[llvm-dev] [RFC] Helping release management

[Hal Finkel via llvm-dev]

----- Original Message -----
> From: "Mehdi Amini via llvm-dev" <llvm-dev at lists.llvm.org>
> To: "Kevin B Smith" <kevin.b.smith at intel.com>
> Cc: llvm-dev at lists.llvm.org
> Sent: Monday, May 2, 2016 4:26:30 PM
> Subject: Re: [llvm-dev] [RFC] Helping release management
> 
> 
> > 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).

+1

The title of each commit should briefly describe what the commit does. If we'd like to prefix the title with [Fix] or similar to indicate commits primarily intended as bug fixes, that sounds useful to me, but not essential. All of the other metadata should appear later in the commit message - it is the presence of this metadata we can search for in the commit logs that will be important.

 -Hal

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

-- 
Hal Finkel
Assistant Computational Scientist
Leadership Computing Facility
Argonne National Laboratory