[llvm-dev] [RFC] Helping release management

[Renato Golin via llvm-dev]

On 3 May 2016 at 00:05, Reid Kleckner via llvm-dev
<llvm-dev at lists.llvm.org> wrote:
> +1 to everything Hans said. We should standardize how we reference bugs from
> commits, and then get better about tagging the issues in ways that are
> useful to release managers.

We have a standard:

http://llvm.org/docs/DeveloperPolicy.html#commit-messages

"If the patch fixes a bug in bugzilla, please include the PR# in the message."

Also, we don't want to control how people write commit messages. There
was a long discussion when we wrote that document, and the consensus
was:

"For minor violations of these recommendations, the community normally
favors reminding the contributor of this policy over reverting. Minor
corrections and omissions can be handled by sending a reply to the
commits mailing list."

Meaning any parsing you may want to do on commit messages will be
broken by the fact that not all of them will be strictly following our
not-strict guidelines.


> I like the idea of a custom phabricator field, so we can make the references
> clickable from reviews.

Customizing Phab is indeed a good idea, but one that is still not a
sure way to get info from. Nor is Bugzilla.

Until now, the mechanism we're using to back-port patches to stable
releases has been for developers to recommend a patch and for the
code-owner to approve (and merge) the back-port. I agree this doesn't
scale to multiple release schedules, but I don't want back-ports going
in without oversight, nor I think we can consolidate all release
management into a tool that can easily go offline for extended
periods, thus unnecessarily delaying the release process.

I think it's perfectly fine for downstream release managers to propose
patches to the upstream release, and then pull their changes from the
release branch, because that will be validated. I also think we could
do more stable releases a year, since less validation is needed for
each incremental one (most tests are automated in test-release.sh) and
the downstream releases will provide us with a further level of
quality assurance that we don't have today.

If we all work together, it's less work for everyone. If we require
that everyone abide to some complicated and obscure rules on commit
messages and tooling usage, we'll make it harder for everyone else.

cheers,
--renato