Hi, Le ven. 28 juin 2019 à 06:06, Anders Broman <a.broma...@gmail.com> a écrit :
> > > Den fre 28 juni 2019 00:44Jason Cohen <kryojen...@gmail.com> skrev: > >> The question about about weather or not adding dissection of additional >> information in a dissector is an enhancement or a bug; I think this is kind >> of a grey area. If a dissector doesn't completely dissect a header, would >> a patch that completes it be considered fixing it? Does it switch between >> a fix and enhancement if the reason the field is missing is either a wrong >> offset, or a missing proto_tree_add_item statement? >> >> How about handling vendor specific decodes? Particularly where the >> vendor formerly provided a plugin (under an open source license) and kept >> it up to date as formats and data changed. When Wireshark.org opted to >> pull a version of it into libwireshark (which is a good idea) negatively >> impacts the release of updates. Wireshark is not beholden to a vendors >> release cycle and a vendor isn't beholden to Wiresharks. But when they do >> not coincide, functionality that would readily be available is now blocked >> and delayed. Furthermore, with the inclusion of the now incomplete >> dissector it makes it unmanageable to provide the full vendor functionality >> as a plugin. >> >> I think there should be some level of flexibility to the inclusion of >> dissector updates under these circumstances. >> >> As a specific example I am referring to: >> https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=15876 >> >> Jason >> > > It's a slippery slope either way. One can also argue that using the > development version is a possibility. At one point Ubuntu was not taking > our minor versions but rader did their own with security fixes only. So > there's different views on the subject. > > I'm not opposed to make an exception in this case however as the change > is small. What does other people think? > Personally I consider adding new fields / new versions of a protocol as being an enhancement (that's what I do for the dissectors I maintain). If we do an exception here, how will we handle the next request and justify if we refuse the backport? We might open a can of worms here. The development builds are most of the time stable enough for a day to day use. Just my 2 cents, Pascal.
___________________________________________________________________________ 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
