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

Reply via email to