[llvm-dev] [RFC] Helping release management

[Renato Golin via llvm-dev]

On 11 May 2016 at 01:48, Frédéric Riss <llvm-dev at lists.llvm.org> wrote:
> I’ve been doing quite a bit of that lately. The problem is not when you cut
> the branch, but how you maintain it. For multiple months after you branched,
> you’re willing to take fixes for miscompiles. So you have to got through
> every commit and gauge the risk/benefit, see if it applies, if it passes the
> tests…

Indeed!

However, during our "commit message" discussion [1], the consensus was
that too many rules means everyone will forget one or the other and
the result will be worse. So we have to be careful with what we ask.


> Anything that helps tracking that a particular commit need followup commits
> to be fully functional would be a win. I think just mentioning the original
> commit in the followups is a minimum (then you can have tooling to relate
> the commits), but I don’t see a way to enforce this.

The commit message guideline [2] already says that:

 * If the commit is a bug fix on top of another recently committed
patch, or a revert or reapply of a patch, include the svn revision
number of the prior related commit.


> It’s not always easy to distinguish between the first four, and you really
> want to understand it before cherry-picking in a long living branch.

Right now [2], we already have [TAG]s, PR mentions, and NFC flags to
account for most of what you want, but we do not have the set { opt /
codegen / crash } for what the fix is.

It is an interesting idea, and I try to do that myself as free text as
often as possible. But even if we add that, it still will be
considered "guideline", not a "rule", and therefore candidate for
being ignored like all the others.

I personally like rules, and wouldn't mind some git hooks on commit
messages, but the risk of false positives and maintenance of hooks is
one that we cannot ignore. The alternatives are to either close down
the commit access like the GCC folks do, or to impose a culture of
backlash like the Kernel folks do.

That was discussed [1] and the consensus is that we prefer to have
guidelines and keep reminding people to be responsible.

cheers,
--renato

[1] http://lists.llvm.org/pipermail/llvm-dev/2014-September/077089.html
[2] http://llvm.org/docs/DeveloperPolicy.html#commit-messages