Robin, Were you thinking of chatting off list? If so, how and when?
-AK On Tue, Oct 15, 2013 at 7:09 PM, anthony kasza <[email protected]> wrote: > I like the idea of associating a commit hash to a version of a > package. I didn't consider that and it's clever. That would make > development of package much more fluid and assure a 'point in time' > version of any package. > > My thoughts were to offer zero guarantee around package stability or > trustworthiness to users (other than the package will install, > uninstall, etc with broctl) unless the package is included in the Bro > project. This would prevent the Bro team from having to manage too > much. Package versioning, stability, and questions/support would be > left up to package authors and package trustworthiness would be up to > public reputation. This is generally how community apps are handled > for Splunk. > > No matter how versioning is done, an announcement to all package > authors should go out when new version of Bro are cut so to ensure > interoperability. > > -AK > > On Tue, Oct 15, 2013 at 9:46 AM, Siwek, Jonathan Luke > <[email protected]> wrote: >> >> On Oct 14, 2013, at 7:24 PM, anthony kasza <[email protected]> wrote: >> >>> My thought was for the universe database to contain the following >>> pieces of information (taken from the project page): name, URL, >>> author, tags, package version, Bro version, dependencies, license, >>> description. >> >> I think that sounds ok, though details of how package versioning will work >> may need some fleshing out up front. Maybe one question to answer first: >> what level of stability and trustworthiness is expected from the universe? >> >> I'd say a git commit hash for versioning could give some of both. Stability >> in that external repos can progress as fast as they want, but the universe >> metadata should still point to a valid version. Trustworthiness in that >> it's known a universe maintainer reviewed the code associated with the hash. >> Problem is that a git commit hash is per-repository, but per-package >> versioning might be needed (i.e. limit of one package per repo w/ this >> scheme). >> >> - Jon > > > On Tue, Oct 15, 2013 at 9:46 AM, Siwek, Jonathan Luke > <[email protected]> wrote: >> >> On Oct 14, 2013, at 7:24 PM, anthony kasza <[email protected]> wrote: >> >>> My thought was for the universe database to contain the following >>> pieces of information (taken from the project page): name, URL, >>> author, tags, package version, Bro version, dependencies, license, >>> description. >> >> I think that sounds ok, though details of how package versioning will work >> may need some fleshing out up front. Maybe one question to answer first: >> what level of stability and trustworthiness is expected from the universe? >> >> I'd say a git commit hash for versioning could give some of both. Stability >> in that external repos can progress as fast as they want, but the universe >> metadata should still point to a valid version. Trustworthiness in that >> it's known a universe maintainer reviewed the code associated with the hash. >> Problem is that a git commit hash is per-repository, but per-package >> versioning might be needed (i.e. limit of one package per repo w/ this >> scheme). >> >> - Jon > > > On Tue, Oct 15, 2013 at 9:46 AM, Siwek, Jonathan Luke > <[email protected]> wrote: >> >> On Oct 14, 2013, at 7:24 PM, anthony kasza <[email protected]> wrote: >> >>> My thought was for the universe database to contain the following >>> pieces of information (taken from the project page): name, URL, >>> author, tags, package version, Bro version, dependencies, license, >>> description. >> >> I think that sounds ok, though details of how package versioning will work >> may need some fleshing out up front. Maybe one question to answer first: >> what level of stability and trustworthiness is expected from the universe? >> >> I'd say a git commit hash for versioning could give some of both. Stability >> in that external repos can progress as fast as they want, but the universe >> metadata should still point to a valid version. Trustworthiness in that >> it's known a universe maintainer reviewed the code associated with the hash. >> Problem is that a git commit hash is per-repository, but per-package >> versioning might be needed (i.e. limit of one package per repo w/ this >> scheme). >> >> - Jon _______________________________________________ bro-dev mailing list [email protected] http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev
