xactly happens.
>
> Johanna
>
> On 10 Dec 2020, at 18:06, Robin Sommer wrote:
>
> > It's interesting how different people have different intuitions on
> > semantics here. I also see it as consistent with function arguments,
> > that's why I'd be fine it. That said,
ng. (And maybe no warning if the body doesn’t use any of the outer
> variables, since that form will continue to work.)
>
> — Vern
> ___
> zeek-dev mailing list -- zeek-dev@lists.zeek.org
> To unsubscribe send an email to zeek-d
hen new macOS release come out (but not the Xcode image).
> https://github.com/zeek/zeek/pull/1268
Excellent. Look like we're all good with our new policy. Thanks for
driving this forward, Christian!
Robin
--
Robin Sommer * Corelight, Inc. * ro...@corelight.com * www.corelig
ther way:
https://github.com/cirruslabs/cirrus-ci-docs/issues/218
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
in that page:
>
> https://github.com/zeek/zeek/wiki/Platform-Support-Policy
>
> Let me know your thoughts...
>
> Thanks,
> Christian
--
Robin Sommer * Corelight, Inc. * ro...@corelight.com * www.corelight.com
___
zeek-dev mailing li
t behind it?
One more OS to add is macOS. While nobody knows the deadlines there,
we should record how far back we go in supporting previous versions,
and what package management we're assuming for dependencies (Homebrew
I suppose).
Robin
--
Robin Sommer * Corelight, Inc. * ro...@corelight.c
e'll need to do is define
the per distribution policies. You could add a 1st stab at that to the
calendar as well, or we can do it afterwards.
Robin
--
Robin Sommer * Corelight, Inc. * ro...@corelight.com * www.corelight.com
___
zeek-dev mailing list --
lly catch up to new C++ features eventually (which is
> the main motivation), but we can also steadily modernize our CMake
> scaffold, Python scripts, and so on.
--
Robin Sommer * Corelight, Inc. * ro...@corelight.com * www.corelight.com
___
ze
chieves
all that already, but it has indeed been designed as an incremental
path forward rather than a lets-redo-it-from-scratch approach. Happy
to discuss if that's the right trade-off.
Robin
--
Robin Sommer * Corelight, Inc. * ro...@corelight.com * www.corelight.com
Python API.
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
To summarize this a bit, below is what I think what I heard so far.
Feel free to respond further, I'll move this over into the ticket
later once we have consensus.
Robin
- General preference to keep packages in individual repositories
hosted inside a new GitHub organization "zeek-packages".
On Mon, Aug 24, 2020 at 14:15 -0700, Jon Siwek wrote:
> * What's the LTS policy for packages?
Good question. I think would tie it to the Zeek LTS policy, with a
"blessed" version of the meta-package that we recommend (and maintain)
for each currently maintained Zeek version.
Rob
uard 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. *
an manage
dependencies already. So the "collection" I mentioned could be a
meta-package that depends on all the ones we want. We might need to
make that a bit more explicit for this use case (like you say for
example in the output of "list"), but the basic functionality is
there.
Robin
ple to install a set of default packages now that these won't come
with Zeek itself anymore. Some of the schemes above make that easier
than others.
Thoughts/opinions/more ideas?
Robin
--
Robin Sommer * Corelight, Inc. * ro...@corelight.com * www.corelight.com
_
ult is.
>
> Anyone who has additional heuristics of goodness to add, also chime in with
> them. We'll probably, after consensus, enact change by sending some PRs to a
> few packages to unify them more. I did a sort of census last evening. Of 273
> tags used, I would bani
16 matches
Mail list logo
