Re: [tcpdump] After setjmp/longjmp update

[Bill Fenner via tcpdump-workers <tcpdump-workers () lists tcpdump org>]

> --- Begin Message ---
>
>
> From: Bill Fenner <fenner () gmail com>
>
> Date: Wed, 6 Jan 2021 07:56:10 -0500
>
> 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