Hi, I find that a lack of protocol documentation often makes it hard to check details that would make fixing simple bugs or investigating apparent inconsistencies easier.
I could give check_dissector_urls.py similar command-line options to cppcheck.sh (i.e. support '-l 1' to only consider the files in this commit), which should then only take a few seconds to run for most dissectors. We could potentially also run it over all of the dissectors on the Ubuntu buildbot - for me it took around 35 minutes. I or someone else could just go through all of the broken links and try to look for where they have moved to, or find the original pages/docs using the Wayback Machine, but there may be better/different links, so it'd be good to find a way to get someone actually working with that dissector to supply a link to what they are consulting. Even with IETF specs, we found lots of expired drafts or links to obsoleted RFCs. If you look at the changes for some of the old dissectors, almost all of them are just maintenance that wouldn't require detailed knowledge of the protocol. The suggestion is having it emit warnings that would make a new Petri-dish check go yellow, and could be flagged in reviews. Could even use it to flag if a dissector has no documentation links (though some will just give a clear spec number rather than give a full URL). We wouldn't want it to hinder general changes (e.g. API updates) from being merged because the maintainer doesn't know a better URL. Another reason to only give warnings is that trying to fetch the link could fail for temporary reasons. Any thoughts on this? Martin
___________________________________________________________________________ Sent via: Wireshark-dev mailing list <wireshark-dev@wireshark.org> Archives: https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
