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 On Fri, Dec 13, 2013 at 11:08 AM, "C. Bergström" <cbergstrom at pathscale.com> wrote:> On 12/13/13 01:58 PM, Bill Wendling wrote: >> >> That’s a long laundry list of bugs there. It would be great to have them >> fixed, but the reality of the situation is that they won’t be fixed for >> weeks or more, if at all. And with Christmas coming up, it makes things even >> worse. There are a few days before Phase III starts to have some progress on >> them. But if they don’t make it, then we’ll have to release without them. > > How is the release schedule and blockers decided - is there a policy? As an > open source project it seems sorta weird (to me) that rushing a release is > more important than "getting it right" - granted if it's unlikely any fix > date I can totally see your point.. > --------- > (bw - You do an awesome job of being release manager and please don't take > this as a critique - just curious) > > _______________________________________________ > cfe-dev mailing list > cfe-dev at cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev-- With best regards, Anton Korobeynikov Faculty of Mathematics and Mechanics, Saint Petersburg State University
----- 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-criteriaFair enough, however, I view releasing a compiler which is known to miscompile code on a tier-1 platform as a serious problem. 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. 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. Thanks again, Hal> > On Fri, Dec 13, 2013 at 11:08 AM, "C. Bergström" > <cbergstrom at pathscale.com> wrote: > > On 12/13/13 01:58 PM, Bill Wendling wrote: > >> > >> That’s a long laundry list of bugs there. It would be great to > >> have them > >> fixed, but the reality of the situation is that they won’t be > >> fixed for > >> weeks or more, if at all. And with Christmas coming up, it makes > >> things even > >> worse. There are a few days before Phase III starts to have some > >> progress on > >> them. But if they don’t make it, then we’ll have to release > >> without them. > > > > How is the release schedule and blockers decided - is there a > > policy? As an > > open source project it seems sorta weird (to me) that rushing a > > release is > > more important than "getting it right" - granted if it's unlikely > > any fix > > date I can totally see your point.. > > --------- > > (bw - You do an awesome job of being release manager and please > > don't take > > this as a critique - just curious) > > > > _______________________________________________ > > cfe-dev mailing list > > cfe-dev at cs.uiuc.edu > > http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev > > > > -- > With best regards, Anton Korobeynikov > Faculty of Mathematics and Mechanics, Saint Petersburg State > University > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >-- Hal Finkel Assistant Computational Scientist Leadership Computing Facility Argonne National Laboratory
Hal Finkel <hfinkel at anl.gov> writes: [snip]> 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.What happened to the LLVM/Clang maintenance release project?
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>