Hi, I don't understand the BigTop use cases and release model in too much detail to have very specific or hard opinions on this, but here's a few high-level observations that hopefully are useful for this discussion:
* AFAICT there's no immediate release that's being blocked by this discussion, so everyone can calm down. An issue was brought up, it's being discussed and I'm sure we'll soon enough have a solution that everyone is happy about. * It sounds like BigTop is doing something that few Apache projects have done before. Thus it's fine to question whether and to what extent existing rules apply. However, at the same time it's good to acknowledge that new rules and consensus on a new interpretation of existing rules may be needed for something like this. It's natural for this process to take some time and involve some misunderstandings along the way. * The convenience binaries many projects are providing are normally the result of building the respective source release (together with any required third party dependencies). As a general rule it should be possible for anyone to reproduce equivalent binaries by following the build instructions included in the source release. * As a recent addition, some projects have started providing also convenience packages containing such dependencies required by the source build as described above. In both cases the contents of all such binary packages should be properly signed and contain appropriate LICENSE and NOTICE files. * As far as I can tell from the discussion, the BigTop repos directory [1] doesn't neatly fit into either of the above categories. I guess the key question here is whether the purpose of BigTop is to be a particular, tested combination of upstream projects or rather a tool for testing and building such combinations. (Or perhaps something else entirely?) * If the former, then each subdirectory of [1] falls fairly conveniently into the traditional concept of convenience binaries built from the source release. The only extra thing you'd need is a proper set of license metadata and signatures for the binaries. * If the latter, it seems to me that it isn't BigTop that should be distributing the packages in [1]. Instead each upstream project should using BigTop as a tool to produce such packages as a part of their own release processes. * In that case there might still be a role for BigTop to provide a central repository for such easily consumable upstream releases. This would be somewhat similar to the discussions that took place a few years ago about whether and how the ASF could host something like the central Maven repository. [1] http://www.apache.org/dist/incubator/bigtop/bigtop-0.3.0-incubating/repos/ BR, Jukka Zitting --------------------------------------------------------------------- To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org