I didn't reply to the original email, but after finishing up some LV changes, I decided to try a comment. Of course this is one of those topics that is difficult to discuss in writing, so please don't use your whiney voice when reading it. I'm simply trying to give insight into our process.
LV is a very complicated piece of software. Like most complicated systems, changes can be characterized by cost, risk, and benefit. These are the what the LV team members use to decide what bugs get fixed and when. Of course bug fixes are also weighed against the development of additional features. There are unfortunately, some bugs that have a low benefit to fixing because they don't affect many users or are purely cosmetic in nature, and they are caused by complex interaction or design defect, and would therefore be both risky and costly to fix. When triage is performed, these bugs frequently find their way at the end of the list. That isn't to say they won't ever be fixed, but these are usually batched together and dealt with when a specific feature is reworked. As an example, units in LV is a unique experiment unlike what I've seen in other programming languages or engineering tools. It works incredibly well and efficiently for most things, but it takes a bit to understand how to use, and it has a few rough edges. It has been that way since LV4 or so. We have intended to revamp units, incorporating various wishlist items and bug fixes, but it is a big task since it has to be 99% compatible with the current behavior, yet deal with hard issues like unitless units (decibels and percentages), and dynamic units for logging situations. For LV6 or 6.1, one of the changes was to redo numeric coercion. While it sounds simple, it involved generated code, arrays, clusters, and various odd corner cases. In redoing the feature, we made simplifications, covered some common cases that were overly difficult before, and generally improved things. Units and charts are still on the list of things that could stand to be improved, and my advice to you is to make sure that bug reports give the engineer good information so they can make good estimates on the cost, risk, and benefit. In particular, they can judge the risk of changes to a particular area, and estimate the time to make the changes, but it is sometimes hard for them to estimate how much time and how many LV users are bothered by a bug. Of course if you are honest, you may have just relegated your bug to the back of the line, but in the end, this thoroughness and honesty will lead to the improvement of LV. Greg McKaskle
