[llvm-dev] [RFC] Helping release management

[Quentin Colombet via llvm-dev]

Hi,

Let me summarize the current status of the discussion to check and propose a path forward.

* Summary *

Basically, the high-level status is:
1. Commits should state when they are fixes.
2. Bugs should be tracked in a PR.

None of these is a hard requirement but instead, best practices that we should remind to the contributors.
For #1, I propose the attached patch for the commit message policy.


* What Is Next? *

Now, moving forward, we should investigate if it is possible to have:
A. Hooks on commit to automatically update some field in Diffusion/Bugzilla when a fix is committed.
B. PRs automatically created for fixes that do not have a PR.

For A, the idea is to have an automatic way to update the PRs (like resolved and fixed with a revision number) when some keywords are set (like fixes PR#). The idea with Diffusion is to have a field that marks the commit has been a fix and that we could manually set if we forgot to set the keyword at commit time.

For B, assuming the PR or Diffusion becomes the way to keep trace of every fixes, it is a matter of making easy to document that we are fixing a bug even if a PR does not exist. Maybe it is possible to have some commit hooks that given a keyword (e.g., fixes PR#New) file a PR with the commit message and marks the PR as fixed (also patch the actual commit message to put the PR number).

Now, regarding how this information could be used by release managers to track what has been pulled in their release, I believe we would need to build additional tools on top of that information, but having this information is the priority IMHO.


* Feedback Needed *

- Is it possible to have commit hooks to set some fields in Diffusion/Bugzilla?
- Is it possible to have commit hooks to create PRs?
- What do people think of the attached patch?

Cheers,
-Quentin



> On May 5, 2016, at 11:47 AM, Robinson, Paul <paul.robinson at sony.com> wrote:
> 
> Filing a PR for *every* fix is overkill.  But filing a PR to express "please merge this to the branch" (if there isn't already a PR) seems reasonable.
> --paulr
>   <>
> From: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] On Behalf Of Reid Kleckner via llvm-dev
> Sent: Thursday, May 05, 2016 10:09 AM
> To: Quentin Colombet
> Cc: llvm-dev
> Subject: Re: [llvm-dev] [RFC] Helping release management
>  
> On Wed, May 4, 2016 at 5:07 PM, Quentin Colombet via llvm-dev <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote:
> Typically, what I had in mind was things like typos/thinko, that are bugs, that we notice a few minutes after we made the “main” commit. I do not want we have to file a PR that is going to repeat what we are going to say in the commit message.
>  
> Yeah, I agree, we shouldn't have to file PRs for that kind of stuff. Quick fixes for the build or tests on other platforms obviously fall into this category.
>  
> Do release managers have problems keeping track of these kinds of changes in practice, though? You can always cut the branch from some quiescent period on the weekend of night before the cut.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160516/827fa43d/attachment-0002.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: commitMessage.patch
Type: application/octet-stream
Size: 929 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160516/827fa43d/attachment-0001.obj>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160516/827fa43d/attachment-0003.html>