>> 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 <[email protected]> wrote: > > > On Fri, 28 Jun 2019 at 13:49, Jason Cohen <[email protected]> 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 < >> [email protected]> wrote: >> >>> >>> >>> On Fri, 28 Jun 2019 at 06:50, Pascal Quantin <[email protected]> >>> wrote: >>> >>>> Hi, >>>> >>>> Le ven. 28 juin 2019 à 06:06, Anders Broman <[email protected]> a >>>> écrit : >>>> >>>>> >>>>> >>>>> Den fre 28 juni 2019 00:44Jason Cohen <[email protected]> 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 <[email protected]> > Archives: https://www.wireshark.org/lists/wireshark-dev > Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev > mailto:[email protected] > ?subject=unsubscribe
___________________________________________________________________________ Sent via: Wireshark-dev mailing list <[email protected]> Archives: https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev mailto:[email protected]?subject=unsubscribe
