LLVM 3.9 RC binaries should NOT disable assertions.

Hi All,

I recently learned that the RC binaries are built without assertions, the same way the actual releases are built. This seems like a serious bug to me. We should be looking for assertion failures during RC testing, not hiding them.

So why are assertions disabled? I suggest we enable assertions in RC binaries right away.

/Eric

I think it's correct to test the same configuration that is shipped. I can see it being useful to *also* test asserts-enabled builds, but the RCs and final release should be built identically IMO.

I share the same basic opinion as Duncan, it makes me uncomfortable to not test what is shipped.
Also users have to know that their compile-time will regress with RC compared to release.
Maybe we could put both build online?

I would argue that you should build the RC and the release the same way. I’ve had to fix bugs were someone had an assert with a side-effect, and the code with asserts turned off didn’t work.

I would argue that you should build the RC and the release the same way.

I've had to fix bugs were someone had an assert with a side-effect, and the
code with asserts turned off didn't work.

OK, so it's clearly important to provide and test against RC's in the
actual release configuration, especially since assertions can introduce
bugs on their own.
Arguably however assertions catch more bugs that they cause and if an
assertion is firing in a RC that's a bug and we should want to know about
it.

Simply providing both configurations is a good start but I think we want
our releases to be assertion free and ensuring that should
be part of the releases process.

Those are my 2 cents at least.

/Eric

AFAIK there are no public bots for the release branches; it’s just Hans or Tom, and their cadre of release elves, doing everything manually (?). It’s unlikely to be worthwhile to replicate the entire bot farm to watch release branches with their relatively tiny amount of activity and limited lifespan, but it might be worth having a representative set that could be pointed to each successive release branch as they occur. We never (intend to) have more than one going at a time, IIUC, so relatively few bots would be needed.

–paulr

FWIW, I always test rc1, rc2 and so on with assertions on. Only for the "final" rc, I turn them off.

-Dimitry

Release Candidates are candidates for becoming the release. They should be builds that could simply be renamed to the release (perhaps with changes to the version string, but nothing else). Builds that have additional testing code enabled are called betas.

David

AFAIK there are no public bots for the release branches; it's just Hans or
Tom, and their cadre of release elves, doing everything manually (?).

Yup.

It's unlikely to be worthwhile to replicate the entire bot farm to watch release
branches with their relatively tiny amount of activity and limited lifespan,
but it might be worth having a representative set that could be pointed to
each successive release branch as they occur. We never (intend to) have
more than one going at a time, IIUC, so relatively few bots would be needed.

I, unfortunately, agree with both sides. I think we should test what
we release and also agree we should test with assertions.

Buildbots won't scale, and if we only do a limited set, they might end
up being irrelevant and time wasting. Unless we make the whole process
done by bots (which was discussed in the past as is an interesting
idea), but that's hardly ever coming to light in the next few months.

I don't have a better solution than to put both binaries up for the
RCs, but that won't fix, because people will invariably pick one
instead of the other.

I don't even know what's the real value of the release candidate
binaries, as it seems not many people try them out via download,
instead of building their own, which would make this discussion moot.

cheers,
--renato