Re: Question about dissector "enhancement" / bug

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

On Fri, 28 Jun 2019 at 15:15, Maynard, Chris <Christopher.Maynard () igt com>
wrote:

> You can find the download link by navigating from
> https://www.wireshark.org/ -> Download -> More downloads and
> documentation can be found on the downloads page
> <https://www.wireshark.org/download.html> -> Live on the Bleeding Edge:
> You can download source code packages and Windows installers which are
> automatically created each time code is checked into the source code
> repository.  These packages are available in the automated build section
> <https://www.wireshark.org/download/automated/> of our download area.
>
>
>
> - Chris
There's also the semi-direct link on the Website from Develop -> Latest
Builds.


> *From:* Wireshark-dev [mailto:wireshark-dev-bounces () wireshark org] *On
> Behalf Of *Jason Cohen
> *Sent:* Friday, June 28, 2019 9:36 AM
> *To:* Developer support list for Wireshark <wireshark-dev () wireshark org>
> *Subject:* Re: [Wireshark-dev] Question about dissector "enhancement" /
> bug
>
>
>
> > > 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.
>
>
>
> 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>
> wrote:
>
>
>
>
>
> 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
>
>
>
>
> --
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