Return-Path: X-Original-To: apmail-incubator-general-archive@www.apache.org Delivered-To: apmail-incubator-general-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 7A0E7C15C for ; Fri, 4 May 2012 15:59:10 +0000 (UTC) Received: (qmail 28437 invoked by uid 500); 4 May 2012 15:59:09 -0000 Delivered-To: apmail-incubator-general-archive@incubator.apache.org Received: (qmail 28093 invoked by uid 500); 4 May 2012 15:59:09 -0000 Mailing-List: contact general-help@incubator.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: general@incubator.apache.org Delivered-To: mailing list general@incubator.apache.org Received: (qmail 27969 invoked by uid 99); 4 May 2012 15:59:09 -0000 Received: from minotaur.apache.org (HELO minotaur.apache.org) (140.211.11.9) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 04 May 2012 15:59:09 +0000 Received: from localhost (HELO mail-gy0-f175.google.com) (127.0.0.1) (smtp-auth username phunt, mechanism plain) by minotaur.apache.org (qpsmtpd/0.29) with ESMTP; Fri, 04 May 2012 15:59:09 +0000 Received: by ghbz2 with SMTP id z2so2992929ghb.6 for ; Fri, 04 May 2012 08:59:08 -0700 (PDT) Received: by 10.60.30.3 with SMTP id o3mr9349064oeh.9.1336147148044; Fri, 04 May 2012 08:59:08 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.232.6 with HTTP; Fri, 4 May 2012 08:58:47 -0700 (PDT) In-Reply-To: <4FA31511.7050207@cloudera.com> References:

<4F9F4F6C.4000404@apache.org>

<4FA2D5F3.5060701@apache.org> <4FA31511.7050207@cloudera.com> From: Patrick Hunt Date: Fri, 4 May 2012 08:58:47 -0700 Message-ID: Subject: Re: [DISCUSS] BOM and supported platforms for Bigtop 0.4.0 To: general@incubator.apache.org Cc: "Owen O'Malley" , =?ISO-8859-1?Q?Bruno_Mah=E9?= , bigtop-dev@incubator.apache.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable It's not the job of the incubator to create new rules, but rather to help podlings to graduation while following existing Apache guidelines. It's very clear from http://www.apache.org/legal/resolved.html that what has been proposed is acceptable under existing Apache rules. Bigtop is building on/around ASL licensed software (packaging, iteroperability tests, utilities, etc...), much like many other Apache projects, much like other distributions do with Apache's own projects/software. I don't see any reason to create new rules which limit the podling's ability to include compatibly licensed software in their releases. (as long as they follow the licenses of said software) Patrick On Thu, May 3, 2012 at 4:30 PM, Bruno Mah=E9 wrote: > Hi, > > Please see my reply inline. > > On 05/03/2012 04:00 PM, Owen O'Malley wrote: >> On Thu, May 3, 2012 at 12:01 PM, Bruno Mah=E9 wrote: >>>> >>>> As a mentor of the Bigtop project, I don't see it as acceptable for an >>>> Apache project to distribute binaries of non-Apache software. If the >>>> owners of the Hue project decide to donate it to Apache and it had >>>> been released by Apache, then it would be acceptable. I'm strictly -1 >>>> on releasing any version of Bigtop with Hue or any other non-Apache >>>> software as part of the release. >>>> >>>> -- Owen >>> >>> >>> As part of mentoring Apache Bigtop (incubating) project, it would also >>> be greatly appreciated if you would explain why this -1. >>> >>> Apache Bigtop (incubating) does not and will not include anything that >>> does not belong to the Apache Foundation. >>> So I am really confused as to why this strong reaction. >> >> The strong reaction is because Roman was proposing a Bigtop release >> with rpms and debs for non-Apache projects. That is a non-starter. >> Apache will not distribute non-Apache projects. Saying that Bigtop >> does not release the projects that it incorporates is not justified >> given the fact that Bigtop is putting rpms of each of the incorporated >> projects into /dist/incubator/bigtop. The 2.9GB size of the latest >> Bigtop release has already caused infrastructure significant >> headaches. >> > > Seems like you are still (this is not the first time this is explained > to you) conflating Apache releases on which members vote on, with > convenience artefacts. > Apache Bigtop (incubating) releases are not the packages. Apache Bigtop > (incubating) releases are Apache Bigtop (incubating) source code. > RPMs and DEBs are convenience artefact. > If they are not that convenient to the Apache Foundation, I don't see > the issue with not distributing the ones that are not convenient. > > As far as I know, Apache Infra was only asking for heads up. Which we > will provide and we will pay attention to work more closely with them. > I also fail to see the relationship between the size of the convenience > artefacts and the bill of materials for the coming release of Apache > Bigtop (incubating), which I repeat only contains Apache Bigtop > (incubating) source code. > > So now we have establish that you issue is about the convenience > artefacts, I don't see any remaining issue with Apache Bigtop > (incubating) releases. > > >>> The convenience artefact may pull Hue in, but this is in no way >>> different from Apache Hadoop pulling in Google protocol buffer or Googl= e >>> guava. So again, how is this different? Is Apache Hadoop going to >>> avandon Google Protocolbuffer? >> >> There is a big difference between referencing external projects that >> are required for your project's functionality and incorporating >> non-Apache projects into your project and publishing releases of them >> using independent artifacts. When the user installs a Hadoop rpm, the >> protobuf.jar is there under the hood, but is considered an >> implementation detail that is required for Hadoop to run. >> >> I'd complain similarly if Hadoop was downloading protobuf tarballs, >> making changes to protobuf, making protobuf rpms with those changes, >> and publishing those rpms on Apache's servers. >> > > In any case, there is still distribution of a non-Apache project's > artefacts by both projects. > You either distribute artefacts of it, or you don't. Here the end goal > is not to provide packages, but a deployable big data stack. Packages > are just a mean to an end. > We don't distribute upstream projects, they are dependencies. > > >> However, it goes deeper than than that. If the user installs Bigtop's >> rpms and hits a bug do they contact Hue or Bigtop? Furthermore, I'm >> sure the links that are displayed when you run Bigtop's Hue point off >> to Cloudera's bug and support system. That kind of branding is not ok >> for an Apache project. >> > > Hue is not even integrated into Apache Bigtop (incubating). So let's > cross that bridge when we get there. And in any case, this is an issue > that can be fixed trivially, so I wouldn't make it a blocker. > > But beyond that, we don't patch anything. So any product issue would > come from the product. Any integration issue would be an Apache Bigtop > (incubating) issue. The same way with Apache Hadoop. > No matter what you do, educating users will be the most important part. > > >> Even with Apache projects, Bigtop may become problematic. Look at the >> mess that happened when Lucene made a bugfix release of Apache Commons >> CSV. Lucene needed a bugfix release of CSV, didn't wait for CSV to >> release, and instead released it themselves. Needless to say Apache >> Commons didn't like that result. Bigtop is overriding decisions made >> by the upstream projects about things like the way the launching >> scripts operate and where the configuration directory is. When asked >> to correct it, they complain about compatibility for their users >> rather than compatibility for Hadoop's users. >> > > How is this related with Hue? > I am also not sure about the point of complaining about this here on > general@. This is a direction taken by the Apache Bigtop (incubating) > community at large. You may not agree, but there is a consensus on that > part. Unless there is something in the Apache Foundation bylaws that > would force an upstream project to force decisions on other communities? > > And beyond that, this is not new. As it was explained in an other thread > to Matt on Apache Bigtop (incubating) mailing list: > Apache Bigtop (incubating) has made the choice from the very beginning > to be close to what GNU/Linux distributions have been doing and what > sysadmins have been used to. This can differ with the experience one may > have with a tarball development of Apache Hadoop. > > Keep in mind also that each component has its own way of doing things. > Each one having its own issues. > Apache Bigtop (incubating) smooth this up and provide an easy and > unified experience to users. Furthermore, we cannot satisfy any whim of > every single upstream components. > > In order to use pristine Apache Hadoop, one would have to be familiar > with its usage and its configuration. Apache Hadoop experience is only > familiar to people *already* familiar with Apache Hadoop. > > So using upstream Apache Hadoop will imply a lot of reading through > forums, documentation and frustration. > For instance, Apache Bigtop (incubating) will pre-set the ulimits for > you, will set up the logging to well-known locations, provide init > scripts and make a pseudo-configuration available to users. > > In a word, Apache Bigtop (incubating) has a different use case than > upstream Apache Hadoop and therefore will be different in some areas. > Or put it differently, upstream projects should focus on what they do > best, which is to work on delivering awesome projects, while in Apache > Bigtop (incubating) we focus on what we do best, which is making a > production quality/ready big data stack. > > And I don't see the issue of caring about compatibility of Apache Bigtop > (incubating) users within the Apache Bigtop (incubating) project. > > But again, all of this is unrelated to this thread. So you may want to > move that discussion to another thread. > > Thanks, > Bruno > > --------------------------------------------------------------------- > To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org > For additional commands, e-mail: general-help@incubator.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org For additional commands, e-mail: general-help@incubator.apache.org