Yes. And to clarify, I meant checking the Header part in messages, and dropping all messages whose Header.time is less than previously received. This was a simple message based state that a node can exhibit and I chose this because it appeared as a simpler choice. My bad.
And you’re right about fuzzing and it’s limitations. I was talking about making fuzzing+dynamic analysis easier for maintainers to provide a simpler but robust enough platform for testing compared to a completely model-driven approach.
The problem (in my opinion) with current method is this is a constant depth graph. As such there might be a case that a package A might be rendered useless because of license incompatibilities caused by it’s dependency on package B. Finding out packages at different levels would be useful and the current list method can be modified to show a graph. A graph also helps to choose the package with minimum proliferation of dependencies in case of two or more similar packages. I do concede that the average ROS user would not be affected by this issue as much a company. (Also, I’ve noted above that this list is what should be displayed, not what wiki is lacking. Current info on wiki isn’t lacking per-se, it’s just spread around a bit)
PS: I don’t think I’ve said this before, but please inform me if I appear confrontational. I find it hard to choose the right sentence structures and … sometimes things go downhill