Huge thanks to our Platinum Members Endace and LiveAction,
and our Silver Member Veeam, for supporting the Wireshark Foundation and project.

Wireshark-dev: Re: [Wireshark-dev] Wireshark-commits: [Wireshark-commits] rev 44161: /trunk/epa

From: Pascal Quantin <pascal.quantin@xxxxxxxxx>
Date: Sun, 19 Aug 2012 14:24:50 +0200
Le 19 août 2012 à 12:40, Sylvain Munaut <246tnt@xxxxxxxxx> a écrit :

> Hi,
>
> I've just seen those changes (filter names) now and I'm really not
> happy with them ...
>
> 1) I explicitely asked this list for objections against the gmr1.xx vs
> gmr1_xx name and I was told that using gmr1.xx made sense given it's
> always the same protocol. And nobody expressed any view against it and
> Andrew said it was a reasonable choice. Now all saved filters /
> examples / ...would have to be changed for really no good reason.
>
> 2) I would really appreciate if the author of the dissector was at
> least CC'ed when doing changes to the dissector ... This is not the
> first time and in every instance, the original commit had to be
> followed by "fixups" commits because the patch author seemed to be
> more concerned with removing warnings at all costs than actually doing
> the right fix ...
>
> Cheers,
>
>    Sylvain

Hi Sylvain,

If you check the mailing list archive you will see that I also raised
this issue regarding filter names for protocols split across several
files. See http://www.wireshark.org/lists/wireshark-dev/201207/msg00258.html
for the mail exchange.
So far only Michael and myself have expressed our opinion on those
"meta" protocols split across several files. Personally I preferred
the previous filter scheme despite the warnings generated by the
checkfiltername.pl script. It would be good if other people were also
giving their feeling (as you did) so that we can decide once for all
whether the dissectors or the script must be changed for this use case
and try to stick to this decision in the future.
Note that the change was done in the development branch only and that
next stable release from this code base is due in a year so we still
have plenty of time to change things.

Regards,
Pascal.