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 D03A2967B for ; Tue, 21 Aug 2012 00:33:11 +0000 (UTC) Received: (qmail 62639 invoked by uid 500); 21 Aug 2012 00:33:11 -0000 Delivered-To: apmail-incubator-general-archive@incubator.apache.org Received: (qmail 62440 invoked by uid 500); 21 Aug 2012 00:33:11 -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 62432 invoked by uid 99); 21 Aug 2012 00:33:11 -0000 Received: from minotaur.apache.org (HELO minotaur.apache.org) (140.211.11.9) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 21 Aug 2012 00:33:11 +0000 Received: from localhost (HELO mail-vb0-f47.google.com) (127.0.0.1) (smtp-auth username robweir, mechanism plain) by minotaur.apache.org (qpsmtpd/0.29) with ESMTP; Tue, 21 Aug 2012 00:33:10 +0000 Received: by vbbfr13 with SMTP id fr13so5997531vbb.6 for ; Mon, 20 Aug 2012 17:33:09 -0700 (PDT) MIME-Version: 1.0 Received: by 10.58.211.100 with SMTP id nb4mr12917161vec.25.1345509189406; Mon, 20 Aug 2012 17:33:09 -0700 (PDT) Received: by 10.220.197.78 with HTTP; Mon, 20 Aug 2012 17:33:09 -0700 (PDT) In-Reply-To: References: Date: Mon, 20 Aug 2012 20:33:09 -0400 Message-ID: Subject: Re: [VOTE] Apache OpenOffice Community Graduation Vote From: Rob Weir To: general@incubator.apache.org Content-Type: text/plain; charset=UTF-8 On Mon, Aug 20, 2012 at 8:11 PM, Greg Stein wrote: > Just because some other podlings have released binary artifacts does > not mean AOO can base their entire release strategy on binaries. > True, But we have not based our entire release strategy on binaries. If you recall we spent a great deal of time preparing the AOO 3.4.0 release, with the vast majority of the work dedicated entirely to the source code aspects of the release. There were very few feature enhancements in that initial release. Our work was highly centered on meeting ASF requirements with respect to pedigree review, license headers, treatment of 3rd party components, LICENSE and NOTICE requirements, etc. > As Marvin has said: source releases are the primary release mechanism. > > Binaries are and should be a distant second. > And that is why we put so much effort ensuring that the source code for OpenOffice met ASF requirements. But we are also releasing binaries, as we did for Apache OpenOffice 3.4.0, and as this project has done for the past 10 years. If you look at our release artifacts, you see that the source tar balls are listed first, followed by binaries: https://cwiki.apache.org/confluence/display/OOOUSERS/Development+Snapshot+Builds Is there some specific method by which the IPMC wishes podlings to make this distinction between the canonical source release and binaries more clear? I've looked at recent podling release approved by the IPMC and I can discern no such distinction. > I would also state that continuing to argue is symptomatic of a > failure to understand and integrate with the Foundation's thoughts on > the matter. Or to at least politely discuss the situation on > legal-discuss. > I would say the lack of understanding could be in both directions, and some greater tolerance would be mutually beneficial. Remember, OpenOffice is unlike anything else previously at Apache. It is an end user product. and a very famous and well adopted one. This does not diminish the importance of the source code artifacts. But it does increase the importance of the binary ones. This is something the PPMC is generally happy with and matches our decade plus experience with the project and the ecosystem. Note also that although we take pride in the 12 million downloads of the binaries, we take even more pride in seeing successful reuses of the code, as we are seeing with non-Apache ports for BSD, OS/2 and Solaris, and work on other non-ASF products based on Apache OpenOffice, including portableApps and WinPenpack. We have PPMC members employed in producing products based on our source code, by three different companies. So we understand the value of the source to the overall ecosystem. But it still remains true that this is an end user application, used by millions of users, and as a project we will need to (and desire) to give it the attention it deserves as well. These two work together, of course, as additional interest in the source drives more investment into the ecosyste, Regards, -Rob Regards, -Rob > Cheers, > -g > > On Mon, Aug 20, 2012 at 7:33 PM, Rob Weir wrote: >> On Mon, Aug 20, 2012 at 5:04 PM, Rob Weir wrote: >>> On Mon, Aug 20, 2012 at 4:32 PM, Marvin Humphrey wrote: >>>> On Sun, Aug 19, 2012 at 8:53 AM, Rob Weir wrote: >>>>> Per the IPMC's "Guide to Successful Graduation" [1] this is the >>>>> optional, but recommended, community vote for us to express our >>>>> willingness/readiness to govern ourselves. If this vote passes then >>>>> we continue by drafting a charter, submitting it for IPMC endorsement, >>>>> and then to the ASF Board for final approval. Details can be found >>>>> in the "Guide to Successful Graduation". >>>>> >>>>> Everyone in the community is encouraged to vote. Votes from PPMC >>>>> members and Mentors are binding. This vote will run 72-hours. >>>>> >>>>> >>>>> [ ] +1 Apache OpenOffice community is ready to graduate from the >>>>> Apache Incubator. >>>>> [ ] +0 Don't care. >>>>> [ ] -1 Apache OpenOffice community is not ready to graduate from the >>>>> Apache Incubator because... >>>> >>>> In my opinion, the issue of binary releases ought to be resolved before >>>> graduation. >>>> >>>> If the podling believes that ASF-endorsed binaries are a hard requirement, >>>> then it seems to me that the ASF is not yet ready for AOO and will not be >>>> until suitable infrastructure and legal institutions to support binary >>>> releases (sterile build machines, artifact signing, etc) have been created >>>> and a policy has been endorsed by the Board. >>>> >>>> One possibility discussed in the past was to have downstream commercial >>>> vendors release binaries a la Subversion's example, which would >>>> obviate the need for all the effort and risk associated with providing support >>>> for ASF-endorsed binaries. For whatever reason, the AOO podling seems not to >>>> have gone this direction, though. >>>> >>> >>> Let's look at the the TLP's that the IPMC has recommended, and the ASF >>> Board has approved in recent months. Notice that a fair number of >>> them releae source and binaries, as does the OpenOffice podling: >>> >> >> Some further documentation of IPMC practice in this regard: >> >>> Apache Lucene.Net -- releases source and binaries >>> >> >> IPMC voted to approve release, and vote post pointed to both source >> and binary artifacts: >> >> http://markmail.org/message/mt3xthcqqng7ftnw >> >>> Apache DirectMemory -- releases source only >>> >>> Apache VCL -- releases source only >>> >>> Apache Hama -- releases source and binaries >>> >> >> The people.a.o directory that was voted on by the IPMC is gone now. I >> suspect it included binaries as well. Certainly now that the podling >> has graduated their release candidates include binaries: >> >> http://people.apache.org/~edwardyoon/dist/0.5-RC4/ >> >>> Apache MRUnit -- releases source only >>> >>> Apache Giraph -- releases source only >>> >>> Apache ManifoldCF -- releases source and binaries >>> >> >> Their most recent vote was withdrawn because they graduated before the >> vote completed, but that IPMC vote post also pointed to both source >> and binary artifacts: >> >> http://markmail.org/message/op7ofi2gudwfov3z >> >> So the recent practice of the IPMC has been to approve releases with >> source and binaries, but also to graduate podlings that do so. >> >> Regards, >> >> -Rob >> >> >>> So I'm not quite sure in what way the ASF "is not ready" for a TLP >>> that releases binaries, or what additional legal or procedural work >>> needs to be done to enable this. As far as I can tell ASF projects >>> release binaries today. >>> >>> I agree, sterile buildbots and code signing are good things to have, >>> and we are working with Infra on this today, and would continue to >>> peruse these avenues as a TLP. >>> >>> In any case, shouldn't the question be whether the podling is ready >>> for the ASF rather than whether the ASF is ready for the poding? ;-) >>> >>> -Rob >>> >>> >>>> Marvin Humphrey >>>> >>>> --------------------------------------------------------------------- >>>> 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 >> > > --------------------------------------------------------------------- > 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