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. If I wait for these bugs to be fixed, we won’t be releasing until late January. And that’s really not acceptable. 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. -bw
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> 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. 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) ---------- I'd love to see a policy added to the Release page about who and what constitutes a release blocker. (Something so bad that schedules be damned that it needs to be fixed) At this point there's a 3.4 Release branch being worked on and trunk is open for destruction... now() vs January() who loses?
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 scheduleTo 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.> 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20131216/e458bb69/attachment.html>