Hi,
Happy-shark was an attempt at a stricter regression test that catches
output changes. By design however it would be very much affected by the
tiniest changes in dissector output. The original plan was to have a
very rich repository of sample traces, but that clearly has not
happened.
I would vote for not moving those generic capture files in the main
repo, otherwise source tarballs can grow even bigger. For reassembly
cases, ideally a small, specialized case can be included in the
Wireshark repo.
What about keeping the repo on GitHub without migrating it to GitLab? It
is unfortunately not maintained, but if someone would pick it up, we can
reconsider moving it to GitLab.
--
Kind regards,
Peter Wu
https://lekensteyn.nl
On Fri, Jan 22, 2021 at 10:49:51PM +0100, Jaap Keuter wrote:
> Hi,
>
> As for the options proposed by Dario,
> 1) git submodules basically pins a specific commit of an external repository into your repository. It also requires additional git commands to checkout and move the ‘pin’ forward when anything is added to the external repo which is desired in the git repo. In my experience it is useful to include specific (release-)tags from external libraries, which develop on their own pace, not s much for development in parallel which is our use case.
> 2) git lfs could be interesting, but also makes it more complex for users, needing to install additional git features. In my experience something to be used strategically, I was a bit underwhelmed when finding 128 byte capture files stored with git lfs.
>
> Although I’ve little experience with happy-shark, in theory I would like to see a (especially a TCP) test suite independent of Wireshark version, which is could probably best served by happy-shark.
>
> Thanks,
> Jaap
>
>
> > On 22 Jan 2021, at 21:15, Dario Lombardo <lomato@xxxxxxxxx> wrote:
> >
> > Talking about your options:
> > 1) my concern here is that we would have 2 repos, with parallel lifecycles, that are not enforced to stay aligned. A change in a dissector would benefit from a test case, but such a testcase in happy-shark would be proposed after the code merge in the main repo. That would slow down the process, wouldn't it?
> > 2) this is the current situation. Ideal in the sense that a change carries the code and the testcase. Suboptimal because as soon as the testcases grow, the repo gets too heavy, as you said.
> >
> > If the concern is not to make the repo too heavy we may investigate other options as well.
> > 1) use git submodules
> > 2) use git lfs
> > Option 2 sounds promising: "Git Large File Storage (LFS) replaces large files such as audio samples, videos, datasets, and graphics with text pointers inside Git". We do have a dataset. Moreover gitlab.com <http://gitlab.com/> supports LFS.
> > Unfortunately I don't have direct experience with either submodules and lfs, hence I cannot provide more than just raw ideas.
> >
> > On Fri, Jan 22, 2021 at 6:25 PM Gerald Combs <gerald@xxxxxxxxxxxxx <mailto:gerald@xxxxxxxxxxxxx>> wrote:
> > Hi all,
> >
> > Years ago we added a repository for dissector regression tests at https://github.com/wireshark/happy-shark <https://github.com/wireshark/happy-shark>. Unfortunately it hasn't received much attention, and instead we've been adding dissector tests in the main repository. Should we
> >
> > - Import happy-shark into GitLab and move our current dissector tests there?
> >
> > - Retire happy-shark and do all of our testing in the main repository?
> >
> > - Something else?
> >
> > I'm leaning toward the first option for the simple reason that it will minimize the number of files we accrue in test/captures.
> > ___________________________________________________________________________
> > Sent via: Wireshark-dev mailing list <wireshark-dev@xxxxxxxxxxxxx <mailto:wireshark-dev@xxxxxxxxxxxxx>>
> > 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@xxxxxxxxxxxxx <mailto:wireshark-dev-request@xxxxxxxxxxxxx>?subject=unsubscribe
