First, thank you very much for taking the time to write a thoughtful reply.
On 05/08/2012 02:08 PM, Greg Stein wrote: > On Mon, May 7, 2012 at 9:48 PM, Bruno Mahé <bm...@apache.org> wrote: >> ... > > It seems that we're talking about this location: > http://www.apache.org/dist/incubator/bigtop/bigtop-0.3.0-incubating/ > >> Again, we don't distribute non-Apache software, > > I didn't find any non-Apache software in the location noted above. > >> as well as we don't >> distribute other Apache software either. > > I found a bunch of Apache software in there. > > So I'd say you're distributing it. > > (not that I believe that is a problem, but let's try and get things > straight here) > But all these files are convenience artefacts. They are not part of a release. I don't see any difference from the Google protocolbuffer binary artefacts found in Apache Hadoop convenience artefacts. Except that instead of all of them being hidden into a giant tarball, they are organized openly inside a repository. >> Since you keep on doing this mistake, there is surely a >> misunderstanding. So it would probably be easier if you could point us >> to other Apache (or non-Apache) software being distributed as part as >> any Apache Bigtop (incubating) releases on which members have voted on? > > I can see anybody looking at that URL location believing that you're > distributing both Bigtop *AND* other Apache software. > > If you're using a different definition of "distributing", then we need > to resolve that situation. I see lots of ASF software being > distributed via that URL. > I don't think I am using a different definition of "distributing. But I would like to stress out that I make a clear distinction between what is distributed as part of an Apache release and what is distributed as part of a convenience artefact. Here is a quote from Owen: "I'm strictly -1 on releasing any version of Bigtop with Hue or any other non-Apache software as part of the release." And we truly do not include anything else then Apache Bigtop (incubating) in Apache Bigtop (incubating) releases. And as far as I can tell, the issue Owen is having is related to convenience artefacts, not releases. We use these upstream projects as dependencies. We don't distribute directly other software in the convenience artefacts of Apache Bigtop (incubating). The output of Apache Bigtop (incubating) can be quite unusual since it is a deployable production quality big data stack. So we need to consider the project as a whole, not just one single part. The release provides the recipes to enable you to build and/or customize such a stack. These recipes include the recipes to build packages, virtual machines, integration, performance and validation tests as well as recipes (puppet recipes) to deploy such stack. But we also provide a validated stack as convenience artefacts. >> And again, Apache releases are what people vote on. not the convenience >> artefacts which are there for convenience and are not voted on. So I >> still don't see any reason to not withdraw your -1 since your only issue >> seems to be related to the dependencies in the convenience artefacts >> (which is standard practice, even within Apache Hadoop) > > It is true that votes only apply to Bigtop releases and not those > artifacts under bigtop-0.3.0-incubating/repos/. > > It is also true that (in normal PMC operation) it is not possible to > veto a release. I have no strong opinion, but would believe the that a > podling can also make a release with three IPMC +1 votes (and, again, > vetoes do not apply). Note: IPMC votes, not PPMC votes. If somebody > raises a -1, then I suspect getting those IPMC votes might be > difficult until the concern is discussed. > > Regarding the release artifacts: I don't have any strong opinions > right now. I can see the confusion with them all in the same location. > I can also see that Infra should probably get involved in some way to > deal with mirroring issues and to somehow distinguish, verify, and > validate these binary artifacts. > >> ... > What confuses me the most, is that Owen's issue is with the convenience artefacts, not with the release itself. So there is no real reason to -1 releases if they are not the issue. And if I understand correctly from what you are saying, there is really nothing preventing us from continuing, providing the Apache Bigtop (incubating) community is in agreement (ie. enough +1 on tickets and enough +1 from IPMC members for releases). Although I would rather end up with everyone agreeing. But in the worst case scenario, we can always stop publishing convenience artefacts as part of Apache releases, and host these convenience artefacts outside of the Apache Infrastructure as contributors and bypass all these concerns. Note also that Infra has already been involved. Thanks, Bruno --------------------------------------------------------------------- To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
