[llvm-dev] [RFC] Helping release management

[Philip Reames via llvm-dev]

On 05/02/2016 02:43 PM, Hal Finkel via llvm-dev wrote:
> ----- 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.
+1

I would be strongly opposed to any proposal which involved putting less 
human readable context in the subject.
>
>   -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
>>