All fair points. I won't push any further.
>> My pulled from the air guess is the set of users that need these
incremental dissector\protocol changes is much smaller than the entire
set of users, and their needs are served by the development branch.
Yes, the set of users is much smaller than the entire set of users, but not insignificant. However, the primary path they follow for support of the F5ethtrailer dissector is F5, not Wireshark.org.
And development branch? By this are you meaning to pull from source and build? This definitely seems to be a smaller sub-set of users. The website doesn't make it appear that there is even a development branch to be had. The downloads area states:
The current stable release of Wireshark is 3.0.2.
It supersedes all previous releases.
You can also download the latest development release (3.0.0rc2)
[which was built 22 Feb, 2019 if you go searching for it] and documentation.
If there was actually a development release to be had that was accessible to the non-compiling public it may be less of a pain point.
Regards,
Jason
Hi,
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:
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.
I think the aim of the policy is to keep the "stable" release as stable as possible, we all know that collateral damage from making a change is possible and the policy aims to reduce this. I have quibbled in the past with changes being back-ported that seem to me to be enhancements for this reason.
My pulled from the air guess is the set of users that need these incremental dissector\protocol changes is much smaller than the entire set of users, and their needs are served by the development branch.
As noted by Pascal, the development branch is (usually) quite stable and it's been my daily driver for a number of years.
--
Sent via: Wireshark-dev mailing list <wireshark-dev@xxxxxxxxxxxxx>
Archives: https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
mailto:wireshark-dev-request@xxxxxxxxxxxxx?subject=unsubscribe
