[llvm-dev] [RFC] Helping release management

[Quentin Colombet via llvm-dev]

Hi Hans,

Since you are actively doing this kind of things, your feedbacks is particularly valuable.
Thanks!

> On May 2, 2016, at 3:45 PM, Hans Wennborg <hans at chromium.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?

When a PR is available, that is certainly good enough.
I do not want to make filling a PR mandatory for each bug we fix though. Having a PR is great, but I can see why we may not want to create one each time we fix something.

If we do want to go into that direction though, I believe we would need to provide more support to make that easier. (E.g. filing via command line, getting a number back and feeding this number to a commit.)

> 
>> 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.

Sounds great to me.

Would that kind of workflow ease your job for tracking what should be pulled into the release branch after you’ve branched?
What would be the best workflow for such task for you?

> 
>> #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).

That would work for me.

Anywhere in the commit message would work as well (like Mehdi and Hal said), though I tend to prefer the first line (but Mehdi does not like it :)).

Cheers,
-Quentin

> 
> Cheers,
> Hans