I'm hoping I can share some news in this area in the next day or two. Until then, here's the best I can do:
A release that contains bug fixes and support improvements but no features is called a Service Release. SRs get a lot less exposure (email, banners, announcements) than minor and major releases, so it's hard to tell how much we do them. We do SRs more often than we do feature releases:
12.0.1 particularly was quite large, taking about as long as a minor release.
Also, here's a few bits of context that may be helpful:
Most of the content in all of our major and minor releases comes from Thwack FRs. A quick skim through past WWWO posts and release notes proves this out.
The original feature request seems to be stating no features, only bugs. Later on, you're mentioning syslog improvements including moving new functionality into the web and web based alerting which definitely feels like a feature. That adds a bit of confusion for me, but honestly I do not add or remove priority from something based on it being a feature or a bug. I want to do the most valuable thing for you guys. We see a lot of bugs that are high value and a lot that are low value. The same is true of feature requests. Most of this comes down to how many people would benefit if a bug is fixed or a feature is added.
12.1, the last release before the currently available 12.2 was focused on old problems: muting alerts and adding support for Meraki in our existing wireless views for example.
Thwack feature requests are super valuable for us to prioritize our work. It costs us and you guys some pain though, because it makes it open and transparent just how many feature requests we get. You guys do an amazing job of dreaming up wildly more functionality than we can hope to deliver. Therefore, we will always have many, even most, feature requests that are years old. A big part of my job is to get the most done for you guys by identifying themes where we can solve many feature requests with a single feature. We'll always be striving to catch up to what you guys dream up though.
Feature request vote counts give an indication of value of the feature but not the cost. In trying to get the most done, we weigh value against cost to implement. If you look at value (votes) alone to prioritize, you end up getting less done for users. I've mentioned this in some threads elsewhere and I can't recall if you were a part of those, so I apologize if I'm repeating here.
Regardless of all of the above, I hear you that you would like more time spent on improving the reliability and completeness of existing features rather than building new things. I appreciate this feedback and will keep it in mind for future prioritization.
Gonna have to completely disagree with you on Web Reports. I took a while to actually start using them as I was quite proficient with Report Writer, but once I started using Web Reports I wouldn't go back to Report Writer if you paid me. The ONLY thing that Report Writer can do right now that Web Reports can't is to allow a report you've written to show up in the web console. Other than that I can do every single thing that Report Writer can do in Web Reports and I can do it 10 times better and 10 times faster. Anybody dissing web reports probably hasn't spent much time learning them. They are incredibly good and far superior in every way to Report Writer. I mean seriously, as a Report Writer lover I can honestly say that this isn't even a close comparison...
Regarding the inability to use Web Reports in other parts of the console: I too would like this, however I also understand that doing it the way Report Writer used to work isn't even possible. A Web Report is more synonymous with a View, not a classic Report Writer report. Something more synonymous with Report Writer would be the Custom Table resource that was added when Web Reports came about.
What I really want to see and I truly hope they are working on is the ability to re-use custom objects (like Custom Tables, Custom Charts, Custom Query resources, etc...) throughout the product. This is actually possible and would fulfill the numerous (however misguided) requests to allow web reports to be planted on views.
The way I'd like to see it work would be if I build a Custom Table for a specific Web Report, I'd like to be able to use that same Custom Table in other Views and Reports throughout the web console. Currently you can only duplicate Custom Tables/Charts within the same report.
Even better would be the ability to re-use the actual custom Data Sources we use to build Custom Tables/Charts. It'd be really cool if we go to put a new Custom Table onto a View/Report and then pick a previously created custom Data Source to drive the new Custom Table/Chart we are building. It'd be even cooler if it worked like SAM Templates in that any changes made to the original Data Source automatically affected all of the Custom Tables/Charts we've built that use that same Data Source. That would be incredibly useful and would tie right in with the type of workflow that people are already used to with Orion since they use this type of "one-to-many relationship" feature not just in SAM Templates but also now with Alert Actions.
A lot of reason that SolarWinds hasn't been addressing some of the other issues you mention (and this is my theory mind you, I don't actually know this to be the case) is that they are still in the early phases of a complete UI refresh. They are moving the entire web console over to a completely new UI framework. This move doesn't just include the front-end "look and feel" of the web console, but actually includes the entire back end, which means Orion will be able to take advantage of newer web technologies like HTML 5 and other stuff that I don't know anything about but that I'm sure is really cool and, more importantly, much faster.
For example: People have been complaining about the Manage Nodes page forever. I myself couldn't figure out why they didn't just tweak some things to fulfill the numerous complaints. Well, the reason was that the time they would spend doing that would only push back the amazing new Manage Nodes page they'd been working on for so long. This new page solves so many complaints that people have had over the years and even adds in new features that I never even knew I wanted. The same thing can be said about their new Polling Engine Upgrade/Installer. It is sooooo good and fixes many gripes people have had over the years. Both of these things still need some tweaking, but they are already leaps and bounds beyond what the old versions offered.
Bottom line is that SolarWinds is a huge company with a TON of moving parts and a client base that is about as diverse as it comes. Furthermore, they aren't making a specialty product that fills a very specific role. Instead they are making an operational "all-in-one" monitoring and management tool that covers everything from deep storage and virtualization monitoring to application monitoring to network configuration management to network device monitoring to DHCP/DNS management to yada yada yada... everything. You can go buy any one specialty tool and it will probably beat SolarWinds in that specific area. However, SolarWinds isn't meant to necessarily replace specialty tools. In medium to large environments those specialty tools are still needed by the administrators of those areas. SolarWinds is geared towards giving a one-stop-shop to operational teams and administrators to give them an all-in-one place to see the status of the whole environment and to even perform some management functionality for certain things. There isn't another product out there with the all-in-one feature set that is as good as SolarWinds in my opinion. Paessler is OK and is definitely a competitor but I think they are still a long way off from coming close. Arguably a well built and managed Nagios environment could probably rival and maybe even beat SolarWinds, but the amount of expertise, experience, and time that would have to be spent to get a Nagios environment to that level and, even more importantly, to keep it at that level, is tremendous. Most companies won't dedicate the resources to finding and paying the person/people capable of doing this when something like SolarWinds is out there.
With such a large product that has so many diverse needs it takes a long time for changes to be implemented. Plus, no matter what they work on they are not going to please everyone and the time they spend working on something means they are not able to spend time working on the 10,000 other things other people want them to work on. They really can't win. However, they do a really good job in my opinion and I have been thoroughly impressed and pleased with the progress they've made and the direction they are going. Except with WPM. That product really needs some love. It's been a long time since it was upgraded. Seriously. A really LONG time...
If it's 5 years old, it may need a couple of bumps to get their attention.. some things go stale, over time. That likely includes old FRs, unfortunately
'll do my but, though! I will look at both, and vote them up if I agree with the content / can replicate the problem.
Ultimately, negativity isn't going to help, although I do understand where your frustration comes from! Are the problems still there, in NPM 12.2?
500 is a good number, it could be that some of these are being looked at, or perhaps will be addressed in a future release of something yet to be disclosed?
Maybe tagging in wabbott or the product manager (where relevant) will help. SWI's devs are only human, and Orion Core itself (so things common to all Orion products) may not have a single PM assigned to it, and hence may not have been picked up.
Not entirely sure this should be filed under a feature request, as a bug fixing pass is not really a feature, as such. Hence, I've down voted it. However, this thread has given me an idea:
As users of the Orion platform, we have a golden opportunity to ensure the bugs that we find are addressed, by reporting them to support. What would be a better idea is a 'bug' reporting section of Thwack, where people can post their bugs, and people can vote that they can reproduce said bug, and provide meaningful data to allow the dev's to find and squish them!
In fact, I'm going to create said feature request, for Thwack itself, right now!
Whilst the tone of this FR is somewhat negative, let's see if we can make something constructive out of it! I'll post the link to the FR here, when I've created it
3) With sufficient thrust, pigs fly just fine. However, this is not necessarily a good idea. It is hard to be sure where they are going to land, and it could be dangerous sitting under them as they fly overhead.
Top Comments