--- Begin Message ---
On Tue, Jan 5, 2021 at 8:10 PM Denis Ovsienko via tcpdump-workers <
tcpdump-workers@lists.tcpdump.org> wrote:
> Bill Fenner via tcpdump-workers <tcpdump-workers@lists.tcpdump.org>
> wrote:
>
> > I just wanted to share some of my thinking about how to proceed with
> > the truncation-related changes on the road to 5.0.0.
> >
> > 1. Improve code coverage for the printer that's being modified. (This
> > ensures that the code being modified has a corresponding test pcap
> > that can be used by steps 2 and 3).
>
> Hello Bill.
>
> It used to be 31 test in tcpdump 4.3.0, now it is 571 test, and the
> coverage is still very far from complete, even more so for less common
> protocols. There is a steady consensus that it would be nice to have
> more tests, contributions are welcome as always.
>
My apologies that this statement seems to have been misconstrued. The
whole point of this statement about improving coverage was in the context
of using trunc-o-matic below. The testing situation *is* improving very
impressively and I would not have made this statement standing alone.
The point here was meant to be: first you have to make sure you have a pcap
that will cause trunc-o-matic to run the code that you're going to change,
and then when you change it and trunc-o-matic gives the same result, you
can be sure that the code change that you made was correct.
> 2. Use the trunc-o-matic tool from
> [...]
>
> Thank you for proposing this new tool. I see a potential for false
> positives, let me have some time to try it and to see if that's actually
> the case.
>
Feedback is absolutely welcome.
> I also think that community members would be willing to chip in if the
> > effort was coordinated (e.g., open a github ticket for each printer
> > that needs this conversion, have a wiki page that talks about the
> > conversion process, etc.). There's no need for the maintainers to
> > take on the work of all of the protocols.
>
> You mean well, but let me suggest after you walk a mile in these
> particular shoes you'll prefer a different wording, or maybe even a
> different idea.
>
> Francois-Xavier started this thread in September 2020 on the assumption
> that community members will want to contribute. It is January 2021 and
> except myself you are the first ever to discuss, thank you. Let's
> concur that in foreseeable future there will be a meaningful amount of
> work that will be never done unless the project maintainers do it.
>
Yes, there will always be a part that nobody will volunteer to do.
However, I believe that one reason that nobody has stepped up to
participate is that it is not very clear exactly what changes needs to be
done and how to measure success. My goal is to lower the bar for external
contributions - not to say that I think that there's someone out there who
will meaningfully fix print-wb.c, but that I think that there are people
out there who could contribute to ospf, bgp, isis, mpls, etc.
I realize that I am suggesting to do more work (documentation) in order to
reduce conversion work by an unknown amount, which could be zero, so as you
suggest I will take a first pass at writing the documentation.
A separate ticket for every file to me seems to be not worth the
> hassle considering how few people need to coordinate now. That said, a
> weekly/fortnightly status update on the list could be a useful addition.
>
Well, another reason that community members may not be participating could
be because it is not at all clear how to avoid duplicate effort. So while
a ticket per file may be too much overhead, I do believe some level of
communication could help. Right now this is opaque from the outside, so we
just end up leaving it all to Francois-Xavier. He has done an amazing job
but also deserves some help.
Bill
--- End Message ---
_______________________________________________
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdump.org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
