Re: Question about dissector "enhancement" / bug

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

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

___________________________________________________________________________
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