[llvm-dev] [RFC] Helping release management

[Sanjoy Das via llvm-dev]

It'd be great if whatever we choose to implement this has a way to add a 
reference to a PR / non-PR'ed bug after the commit is done.  That way 
forgetting to add a PR tag to a commit message is not a big deal, and 
does not require a revert and recommit.  A field in Diffusion that I can 
update manually (but gets autofilled if the commit message has "[FIX]" 
or "PRXXXX") will be perfect.

-- Sanjoy


Reid Kleckner via llvm-dev wrote:
> +1 to everything Hans said. We should standardize how we reference bugs
> from commits, and then get better about tagging the issues in ways that
> are useful to release managers.
>
> I like the idea of a custom phabricator field, so we can make the
> references clickable from reviews.
>
> On Mon, May 2, 2016 at 3:45 PM, Hans Wennborg via llvm-dev
> <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote:
>
>     On Mon, May 2, 2016 at 1:35 PM, Quentin Colombet via llvm-dev
>     <llvm-dev at lists.llvm.org <mailto: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
>     _______________________________________________
>     LLVM Developers mailing list
>     llvm-dev at lists.llvm.org <mailto: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