llvm dev - Aug 2016 - LLVM 3.9 RC binaries should NOT disable assertions.

> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20160815/bffe4b0b/attachment.html>

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

From: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] On Behalf Of Eric
Fiselier via llvm-dev
Sent: Monday, August 15, 2016 3:34 PM
To: Craig, Ben
Cc: LLVM Developers Mailing List
Subject: Re: [llvm-dev] LLVM 3.9 RC binaries should NOT disable assertions.
> 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


-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20160815/6320416b/attachment.html>

On 16 Aug 2016, at 00:33, Eric Fiselier via llvm-dev <llvm-dev at
lists.llvm.org> wrote:
> 
> > 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.
FWIW, I always test rc1, rc2 and so on with assertions on.  Only for the
"final" rc, I turn them off.

-Dimitry

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 194 bytes
Desc: Message signed with OpenPGP using GPGMail
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20160816/a7f70bc2/attachment.sig>

On 15 August 2016 at 23:57, Robinson, Paul via cfe-dev
<cfe-dev at lists.llvm.org> wrote:
> 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