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

[Jack Howarth]

On Wed, Feb 18, 2015 at 1:04 PM, Renato Golin <renato.golin at linaro.org> wrote:
> On 18 February 2015 at 17:04, Jack Howarth
> <howarth.mailing.lists at gmail.com> wrote:
>> Renato,
>>        My concern is that, without strict enforcement of the triaging
>> serious P1-type bugs, the major  llvm.org releases will devolve into a
>> continual exchange of one set of major regressions for another set.
>
> This is a very pessimistic view of our community. We do care about
> bugs and we do tend to fix it pretty quickly, even without the beating
> drum of a release cycle.
>
>
>> Otherwise, folks will decide that the major releases are unsafe and eventually avoid them entirely.
>
> As I said, releases are not meant to be a product, but a point in
> time. If you want do build a product out of a release, I suggest you
> to always wait for the dot-releases, as they have the fixes for
> problems that were found when spinning the release, while keeping
> ABI/API compatibility.
>
> You are expecting our releases to be something it's not, and it's not
> a surprise if that doesn't abide by the level of quality you aspire.
> Most, if not all users don't rely that much on releases and tend to
> pick a commit in between that suit their needs. This is not just
> Apple, as you mentioned, but almost every one do that. Furthermore,
> new versions of GCC *also* have major regressions in some benchmarks
> and they also release and fix on the next dot-release.

Define users. If compiler developers, your argument holds. For other
users who just want a stable compiler, the argument does not. As for
FSF gcc, I disagree. If an egregious  regression in an important
benchmarks is discovered, in general they would escalate it to a P1
and most certainly fix it before release.

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65028
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65006

Especially when the problem is understood and a fix is at hand.

>
> cheers,
> --renato