[cfe-dev] [LLVMdev] [3.6 Release] RC3 has been tagged

Renato Golin renato.golin at linaro.org
Wed Feb 18 08:53:58 PST 2015


On 18 February 2015 at 16:39, Jack Howarth
<howarth.mailing.lists at gmail.com> wrote:
> This still all begs the question of what exact metrics exist for the
> Q/A of llvm releases? IMHO, the bad PR from shoving out compiler
> releases with severe performance regressions in the generated code far
> outweighs a brief delay to triage these issues as much as possible.

Hi Jack,

It depends on how you interpret LLVM releases.

I still see them as points in time where we actually did some deeper
investigations as a community and made sure the compiler is still
sane. If it's not, future points in time shall fix it, for example, on
dot releases or next releases, depending on how severe the regression
is.

A while ago we kind of agreed on a release Go/NoGo table that was
somewhat like this:

Before release:
* Any conformance regressions
* Bad conformance breakage (new)

Next dot release:
* Any conformance breakage
* Bad performance regression

Next release:
* Any performance regression

Since most people use LLVM on top-of-tree, the problem of having a
release that is not as good as the previous is somewhat washed away by
the fact that we now have dot-releases, and can fix the horrible cases
before a new full release comes in 6 months time.

Also, we don't have a limit for dot releases, and last year we had a
dot release almost right after the major release due to similar
problems. So, what we release now won't necessarily go to
distributions, if we continue the process on the next dot-release,
3.6.1.

I think we all agree that this is a "bad performance regression", but
most of us think this is not bad enough to delay the release further,
but probably bad enough to start the next dot release right after the
end of this one.

Does that really sound like such a bad idea?

cheers,
--renato



More information about the cfe-dev mailing list