Re: Question about dissector "enhancement" / bug

[Jaap Keuter <jaap.keuter () xs4all nl>]

Hi Jason,

Indeed, not so easy to find. The roadmap[1] states the intention to have a decent snapshot of the current developments 
in 3.1 posted as development build on the front page at about July 18th.

Thanks,
Jaap

[1] https://wiki.wireshark.org/Development/Roadmap <https://wiki.wireshark.org/Development/Roadmap>


> On 28 Jun 2019, at 15:35, Jason Cohen <kryojenik2 () gmail com> wrote:
>
> > > See the automated build section, dev builds for Windows and OSX: https://www.wireshark.org/download/automated/ 
> > > <https://www.wireshark.org/download/automated/>.
>
> > > These builds are produced when a merge is made to the appropriate master branch.
>
> The point wasn't for me.  ;) it was for the thousands+ of users that depend on wireshark to decode captures that will 
> never see a line of source code or a build bot in their life, let alone know to find build bot artifacts, or that 
> such a thing exists.
>
> On Fri, Jun 28, 2019 at 7:55 AM Graham Bloice <graham.bloice () trihedral com <mailto:graham.bloice () trihedral 
> com>> wrote:
>
>
> On Fri, 28 Jun 2019 at 13:49, Jason Cohen <kryojenik2 () gmail com <mailto:kryojenik2 () gmail com>> wrote:
> 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.
>
>
> See the automated build section, dev builds for Windows and OSX: https://www.wireshark.org/download/automated/ 
> <https://www.wireshark.org/download/automated/>.
>
> These builds are produced when a merge is made to the appropriate master branch.
>  
> Regards,
> Jason
>
>
> On Fri, Jun 28, 2019 at 4:21 AM Graham Bloice <graham.bloice () trihedral com <mailto:graham.bloice () trihedral 
> com>> wrote:
>
>
> On Fri, 28 Jun 2019 at 06:50, Pascal Quantin <pascal () wireshark org <mailto:pascal () wireshark org>> wrote:
> Hi,
>
> Le ven. 28 juin 2019 à 06:06, Anders Broman <a.broman58 () gmail com <mailto:a.broman58 () gmail com>> a écrit :
>
>
> Den fre 28 juni 2019 00:44Jason Cohen <kryojenik2 () gmail com <mailto:kryojenik2 () 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 <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.
>
> 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.
>
> -- 
> Graham Bloice
>
> -- 
> Graham Bloice
> ___________________________________________________________________________
> Sent via:    Wireshark-dev mailing list <wireshark-dev () wireshark org <mailto:wireshark-dev () wireshark org>>
> Archives:    https://www.wireshark.org/lists/wireshark-dev <https://www.wireshark.org/lists/wireshark-dev>
> Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev 
> <https://www.wireshark.org/mailman/options/wireshark-dev>
>              mailto:wireshark-dev-request () wireshark org <mailto:wireshark-dev-request () wireshark 
> org>?subject=unsubscribe
> ___________________________________________________________________________
> 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-request () wireshark org?subject=unsubscribe

___________________________________________________________________________
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-request () wireshark org?subject=unsubscribe