On Mon, Aug 24, 2020 at 11:49 -0700, Johanna Amann wrote:
> This, from my point of view, it would be neat to have a way to still
> easily install a rather large set of packages (potentially nearly
> everything that is in policy at the moment) and run test on them.
While I agree that integration testing is useful, too, ideally the new
packages would primarily rely on tests that are standalone. Do you see
a problem with that for, e.g., the SSL functionality?
> that change a lot of the test baselines - especially when we touch
> something that affects connection-ID hashing, or the order of elements
> in hashmaps.
Agree with Jon here: This might be an opportunity to make the tests
less fragile, more like what we'd recommend for external packages
anyways.
> It would be nice if, afterwards, it would still be possible to install a
> working set of a script for the running version of Zeek.
Yeah, if we worked with a meta-package, we could "bless" a specific
version of that for a given Zeek release. People could update further,
but with less of a guarantee, though we'd try hard to ensure they work
with different versions, can even CI them against a bunch of recent
releases.
Overall, our current policy/ scripts haven't required version-specific
changes very often, so I'm not too worried here. The most common use
case it probably some script starting to use a newly introduced
feature, and that's pretty easy to catch / guard against.
> It would be neat to have a place that contains the combined
> documentation of these scripts.
Agree, and I'd extend that to packages in general, you be a job for an
extended packages.zeek.org to provide autogen'ed documentation.
Robin
--
Robin Sommer * Corelight, Inc. * ro...@corelight.com * www.corelight.com
_______________________________________________
zeek-dev mailing list -- zeek-dev@lists.zeek.org
To unsubscribe send an email to zeek-dev-le...@lists.zeek.org
