[llvm-dev] [Openmp-dev] RFC: Release process changes

[Renato Golin via llvm-dev]

On Mon, 25 May 2020 at 23:10, Hans Wennborg via llvm-dev
<llvm-dev at lists.llvm.org> wrote:
> +1
>
> Maybe even stronger than "is allowed to commit", I think we should
> really think about it as the release manager owning the branch, and
> has full authority over what goes into it or not. Consulting code
> owners often makes sense of course, but for many patches, consulting
> the code owner (when there is one) is an unnecessary slowdown.

Agree, with one condition: this is a "best effort" to speed up the
process, not to create a tug-of-war between release managers and code
owners.

All rules still apply: developers can ask for post-commit reversal if
a problem is found, which can delay the release further and create
merge problems if it flip-flops for too long.


> My first thought is that doing all these releases sounds like a lot of
> work.

Indeed. And AFAIK we don't have that many users for them. Most users
use some form of "internally thoroughly tested stable master".

Back then, we agreed to intermediate releases somewhat reluctantly,
but the overall value of having a "hind-sight more stable final
release" is appealing. Multiple of them? Not sure.

To me it sounds like we're replacing one process with three steps,
where the final step's quality is "guaranteed to our best ability" for
6 one-step processes, but where the quality of any intermediate step
is bound to the same testing rules.

If we test them like "final", now we have *a lot* more work in
between, and if we test them like "RC1", then we can't guarantee
quality.

There is a lot more work than just running a three-stage check +
test-suite. Distros test on their packages, users test on their
projects, etc. I don't think we can scale that process every two
weeks.

I'm happy to be wrong, and if distros, languages and downstream
projects are happy with it, so am I. But I'd ask them first (ie not in
llvm-dev), before taking a decision...

cheers,
--renato