Re: Question about dissector "enhancement" / bug

[Graham Bloice <graham.bloice () trihedral com>]

On Fri, 28 Jun 2019 at 13:49, Jason Cohen <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/.

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>
> wrote:
>
> > On Fri, 28 Jun 2019 at 06:50, Pascal Quantin <pascal () wireshark org>
> > wrote:
> >
> > > Hi,
> > >
> > > Le ven. 28 juin 2019 à 06:06, Anders Broman <a.broman58 () gmail com> a
> > > écrit :
> > >
> > > > Den fre 28 juni 2019 00:44Jason Cohen <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
> > > > >
> > > > > 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>
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