[LLVMdev] [cfe-dev] LLVM 3.4 Branch Freeze

[Bill Wendling]

On Dec 13, 2013, at 3:30 AM, Hal Finkel <hfinkel at anl.gov> wrote:

> ----- Original Message -----
>> From: "Anton Korobeynikov" <anton at korobeynikov.info>
>> To: "C. Bergström" <cbergstrom at pathscale.com>
>> Cc: "cfe-dev at cs.uiuc.edu Developers" <cfe-dev at cs.uiuc.edu>, "Mailing List" <llvmdev at cs.uiuc.edu>
>> Sent: Friday, December 13, 2013 3:24:38 AM
>> Subject: Re: [LLVMdev] [cfe-dev] LLVM 3.4 Branch Freeze
>> 
>> The usual procedure is to make time-based releases. So - "release
>> trunk and make sure it's stable enough" plus - fix any outstanding
>> regressions.
>> 
>> There is some text wrt this:
>> http://llvm.org/docs/HowToReleaseLLVM.html#release-qualification-criteria
> 
> Fair enough, however, I view releasing a compiler which is known to miscompile code on a tier-1 platform as a serious problem.

I don’t disagree with this at all.

> Obviously, we cannot delay a release indefinitely, but it is completely practical to fix all of those bugs in a few weeks: they all have small test cases. I think that what we should do is put names next to as many of those as possible (to assign responsibility), and proceed under the assumption that we'll cut the final release candidate once those assigned bugs have been fixed (my guess is that there are only 5-7 underlying issues behind those various bugs I listed). There are more than enough of us that *work* on LLVM for this to be reasonable.

Those people have their own schedules and priorities. I have absolutely zero control over which bugs they give their time to. If I had someone say “I am working on this and foresee a fix by Monday,” then I would wait. But so far no one has done that.

> FWIW, when I started talking to people about using an LLVM-based compiler in production, a common response was, "how large of a code base have you compiled with it that gets the right answer?" -- and the problem has been that, when testing on multi-million-line internal codebases, miscompiles had been observed. I feel that, as a community, we should take a stronger stance against releasing code with miscompile bugs. Doing so seriously hurts our credibility. Obviously, we can't delay a release because someone somewhere feels that we miscompile something, but having small test cases is another story.
> 
> In short, I feel that going from initial branching to final release in ~1 month is a great goal, but I'd rather make it two months (as Bill points out, there are holidays in the middle) to eliminate these kinds of bugs. I think that, so long as everyone can understand what is going on, our metrics on "release blocking" bugs are clear, and our release manager observes steady progress, then delaying is preferable.
> 
> Finally, I think that very few of us that create products derived from LLVM/Clang strictly track the upstream release schedule, so I suspect that delaying for a few weeks won't affect any of our corporate contributors. Many of my colleagues say that, with gcc, they wait for the x.y.1 release before upgrading because the .0 is too buggy. But if we're not doing point releases, then I think we need tighter standards for release. Doing otherwise is not fair to our users.


-bw

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20131216/606af2aa/attachment.html>