[llvm-dev] [RFC] Helping release management

[Tom Stellard via llvm-dev]

On Mon, May 02, 2016 at 01:35:27PM -0700, Quentin Colombet via llvm-dev wrote:
> 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.
> 
> * Proposal *
> 
> 1. Use [Fix] for commit related to bug fixes.
> 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?
> 
> #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?
> 

Having a centralized place to track bug-fixes and stable patches would
be great.  I think having tags on commits would help, but it won't be
able to cover everything, especially for dot releases where bug fixes
are sometimes identified some time after they have been committed to trunk.

I experimented using phabricator's audit tool for the purpose of tracking
stable patches for the 3.7.1 release.  Advantages of using audit are:

- The audit page has a simple url with the svn revision right in the
  url. e.g. http://reviews.llvm.org/rL12345.
- The audits would appear on the code owner's phabricator page, so they
  would know which patches they needed to approve.
- There was a record of approvals and discussion that was easily
  accessible to everyone.

The problem was, though, that audit is really designed for post-commit
review.  It had states that were analogous to differential's open and
accepted states, but there was no state like closed to indicate that the
patch had been merged to the release branch.  This made it impossible
to do queries to see which patches had been merged, which made it not
very useful for managing the release.

I think phabricator could probably be the best tool for managing
releases, because it is integrated with source control and already has
information about all the commits, but it does not currently have the
right tool/features to make this work.

Hans mentioned in another email about using Bugzilla, and I think this
is a good idea.  If we required users/developers to file a bug for each
patch they wanted merged, then it would be really easy to track.

-Tom


> Thanks,
> -Quentin
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev