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

[Hal Finkel]

----- Original Message -----
> From: "Bill Wendling" <isanbard at gmail.com>
> To: "C. Bergström" <cbergstrom at pathscale.com>
> Cc: "Hal Finkel" <hfinkel at anl.gov>, "cfe-dev at cs.uiuc.edu Developers" <cfe-dev at cs.uiuc.edu>, "Mailing List"
> <llvmdev at cs.uiuc.edu>
> Sent: Monday, December 16, 2013 3:20:48 AM
> Subject: Re: [cfe-dev] LLVM 3.4 Branch Freeze
> 
> On Dec 15, 2013, at 7:10 PM, C. Bergström < cbergstrom at pathscale.com
> > wrote:
> 
> 
> 
> 
> 
> On 12/16/13 09:57 AM, Bill Wendling wrote:
> 
> 
> On Dec 12, 2013, at 11:08 PM, 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..
> Releasing software is more of an art than a science. Any software
> release has bugs (not just our project, any project). The question
> to ask is how severe are those bugs? The balance between the
> severity and how many people are (potentially) impacted by it. Then
> you should keep in mind that we have a 6-month release cycle. So any
> bugs that aren’t fixed now will hopefully be fixed by then.
> I think you're doing an awesome job and I don't disagree with
> anything you've written.. curiosity killed the cat though..
> 
> 
> 
> If I wait for these bugs to be fixed, we won’t be releasing until
> late January. And that’s really not acceptable.
> I'm curious about why... release early, release often? stakeholder
> pressure or just trying to maintain a predictable release schedule
> 
> 
> 
> To have a reasonably predictable release schedule. Also to release
> our testers up so that they aren’t bogged down by a really long
> release. And we have no assurance that the bugs will be fixed,
> because this is all a volunteer effort.
> 
> 
> 
> 
> 
> For those who actively use LLVM as a library, they are encouraged to
> keep current with the main trunk. For those who use the official
> release, they should be made aware of any potential major bugs they
> may come across.
> 
> There is evidence to suggest that these (admittedly severe) bugs,
> some of which have been in the tree for several releases, aren’t
> affecting many people at the moment. I would love to have them
> fixed. But it’s not looking feasible at this time.
> If it wasn't affecting anyone - there wouldn't be a bug report.
> 
> 
> If I understand, it was an automated tool that reported some (all?)
> of those bugs. They test things that normal programmers don’t really
> do.
> 

Almost all of them, and several different tools, as it turns out. Regarding whether these bugs occur in human-written code, I'd like to point out that Kay Tiong Khoo has been auditing many bugs that have been recently fixed (or hidden) by some unknown change. He's bisected a fair number of them down to fixes to other bugs. It might be interested to see how many of those were reported based on human-written code.

Regardless, I'd much rather fix a bug with a 40-line computer-generated test case, than in a million-line human-generated codebase ;)

 -Hal

> 
> 
> I won't speculate how many people that is though or the severity..
> (Once again it's not a critique or disagreeing. ALL software has
> bugs.. just thinking-out-loud)
> 
> 
> The reason why I said that is because some of those bugs have been in
> the tree for several releases now, and several large organizations
> have been using clang on a daily basis and haven’t ran into most of
> these (otherwise, they’d be fixed :-) ).
> 
> 
> -bw
> 
> 

-- 
Hal Finkel
Assistant Computational Scientist
Leadership Computing Facility
Argonne National Laboratory