[llvm-dev] [RFC] Helping release management

[Reid Kleckner via llvm-dev]

+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> wrote:

> 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
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160502/e95b18a7/attachment-0001.html>