The ASF releases source code. We produce it, we develop it, we license it and we release it.
We have also, as a courtesy to the community, released binaries (read: pre- compiled and built s/w) as well. The binaries MUST be based on the actual released code. But the s/w itself is what is produced and released by the PMC. This is not a new or unique question. Heck, httpd for *years* released pre-built binaries as a courtesy to the community (mostly the windows builds). At issue is whether or not binaries can fall under the same "protection" and "authority" as the source code. The question to answer is "what exactly do you want". Do you want the builds done on ASF hardware to be deemed "official" to the exclusion of all other builds? What exactly does "official" mean anyway? IMO, what is important is that the end-user obtains a binary that he/she knows is (1) build from the actual, unadulterated office source code release and (2) was built by someone trustworthy. So having some sort of "build release manager" or takes these binaries, checks that they were built correctly, and then signing the binaries seems, to me, to be enough to cover what we, and the end-users, need. On Aug 24, 2012, at 2:49 PM, Joe Schaefer <joe_schae...@yahoo.com> wrote: > Exactly- just work within the constraints > and there is no practical problem whatsoever. > > > > > >> ________________________________ >> From: Andrew Rist <andrew.r...@oracle.com> >> To: general@incubator.apache.org >> Sent: Friday, August 24, 2012 2:44 PM >> Subject: Re: [VOTE] Apache OpenOffice Community Graduation Vote >> >> >> On 8/24/2012 11:19 AM, Joe Schaefer wrote: >>> Really, all this fuss over the LABELLING of >>> a file being distributed does not add value >>> to either the org, the podling, or the users >>> of the software. Nowhere is it written that >>> you CANNOT DISTRIBUTE BINARIES, however it >>> has always been clear that they are provided >>> for the convenience of our users, not as part >>> of an "official" release. That however does >>> not mean that things like release announcements >>> cannot refer users to those binaries, it simply >>> means those announcements need to reference the >>> sources as "the thing that was formally voted on >>> and approved by the ASF". >> >> Thus... >> >> Binaries created /from /the Official Release? >>> >>> >>> >>> >>> >>> >>>> ________________________________ >>>> From: Dave Fisher <dave2w...@comcast.net> >>>> To: general@incubator.apache.org >>>> Sent: Friday, August 24, 2012 1:56 PM >>>> Subject: Re: [VOTE] Apache OpenOffice Community Graduation Vote >>>> >>>> >>>> On Aug 24, 2012, at 10:09 AM, Rob Weir wrote: >>>> >>>>> On Fri, Aug 24, 2012 at 12:45 PM, Rob Weir <robw...@apache.org> wrote: >>>>>> On Fri, Aug 24, 2012 at 12:32 PM, Marvin Humphrey >>>>>> <mar...@rectangular.com> wrote: >>>>>>> Returning to this topic after an intermission... >>>>>>> >>>>>>> On Tue, Aug 21, 2012 at 6:18 AM, Bertrand Delacretaz >>>>>>> <bdelacre...@apache.org> wrote: >>>>>>>> On Tue, Aug 21, 2012 at 11:54 AM, Jürgen Schmidt >>>>>>>> <jogischm...@gmail.com> wrote: >>>>>>>>> ...As one of the active developers I would have a serious problem if >>>>>>>>> we as >>>>>>>>> project couldn't provide binary releases for our users. And I thought >>>>>>>>> the ASF is a serious enough institution that can ensure to deliver >>>>>>>>> binaries of these very popular end user oriented software and can of >>>>>>>>> course protect the very valuable brand OpenOffice that the ASF now >>>>>>>>> owns >>>>>>>>> as well... >>>>>>>> As has been repeatedly mentioned in this thread and elsewhere, at the >>>>>>>> moment ASF releases consist of source code, not binaries. >>>>>>> My impression from this discussion is that many podling contributors are >>>>>>> dismayed by this policy, and that there is an element within the PPMC >>>>>>> which >>>>>>> remains convinced that it is actually up to individual PMCs within the >>>>>>> ASF to >>>>>>> set policy as to whether binaries are official or not. >>>>>>> >>>>>> If there actually is an ASF-wide Policy concerning binaries then I >>>>>> would expect that: >>>>>> >>>>>> 1) It would come from the ASF Board, or from a Legal Affairs, not as >>>>>> individual opinions on the IPMC list >>>>>> >>>>>> 2) It would be documented someplace, as other important ASF policies >>>>>> are documented >>>>>> >>>>> And 2a) Actually state the constraints of the policy, i.e., what is >>>>> allowed or disallowed by the policy. Merely inventing a label like >>>>> "convenience" or "unofficial" gives absolutely zero direction to >>>>> PMC's. It is just a label. Consider what the IPMC's Release Guide >>>>> gives with regards to the source artifact. It is labeled "canonical", >>>>> but that level is backed up with requirements, e.g., that every >>>>> release must include it, that it must be signed, etc. Similarly, >>>>> podling releases are not merely labeled "podling releases", but policy >>>>> defines requirements, e.g., a disclaimer, a required IPMC vote, etc. >>>>> >>>>> I hope I am not being too pedantic here. But I would like to have a >>>>> policy defined here so any PMC can determine whether they are in >>>>> compliance. But so far I just hear strongly held opinions that amount >>>>> to applying labels, but not mandating or forbidden any actions with >>>>> regards to artifacts that bear these labels. >>>>> >>>>> Consider: If some IPMC members declared loudly that "It is ASF policy >>>>> that binary artifacts are 'Umbabuga'", what exactly would you expect a >>>>> Podling to do, given that Umbabuga is an undefined term with no policy >>>>> mandated or forbidden actions? >>>>> >>>>> There is a seductive appeal to reaching consensus on a label. But it >>>>> avoids the hard part of policy development, the useful part: reaching >>>>> consensus on constraints to actions. >>>> The AOO PPMC was asked to take this discussion along with digital >>>> signature issue to legal-discuss to get advice. Whether or not this >>>> becomes guidance for AOO or official foundation wide policy is ultimately >>>> up to the Board and the Membership. >>>> >>>> Regards, >>>> Dave >>>> >>>> >>>>> >>>>>> 3) That the policies is applied not only to AOO, but to other podlings >>>>>> and to TLP's as well. >>>>>> >>>>>> Until that happens, I hear only opinions. But opinions, even widely >>>>>> held opinions, even Roy opinions, are not the same as policy. >>>>>> >>>>>> -Rob >>>>>> >>>>>>>> OTOH I don't think anybody said the ASF will never allow projects to >>>>>>>> distribute binaries - but people who want to do that need to get >>>>>>>> together (*) and come up with a proposal that's compatible with the >>>>>>>> ASF's goals and constraints, so that a clear policy can be set. >>>>>>> I'm concerned that such an effort may not be completed, and that once >>>>>>> the >>>>>>> podling graduates, AOO binaries will once again be advertised as >>>>>>> official, >>>>>>> placing the project in conflict with ASF-wide policy. It may be that >>>>>>> some >>>>>>> within the newly formed PMC will speak out in favor of the ASF status >>>>>>> quo, but >>>>>>> as their position will likely be inexpedient and unpopular, it may be >>>>>>> difficult to prevail. >>>>>>> >>>>>>> Of course I don't know how things will play out, but it seems to me that >>>>>>> reactions from podling contributors have ranged from discouraged to >>>>>>> skeptical >>>>>>> to antagonistic and that there is limited enthusisasm for working >>>>>>> within the ASF >>>>>>> on this matter. >>>>>>> >>>>>>> Gaming out this pessimistic scenario, what would it look like if the >>>>>>> Board >>>>>>> were forced to clamp down on a rebellious AOO PMC to enforce ASF policy >>>>>>> regarding binary releases? >>>>>>> >>>>>>> If we believe that we are adequately prepared for such circumstances, >>>>>>> then I >>>>>>> think that's good enough and that fully resolving the issue of binary >>>>>>> releases prior to AOO's graduation is not required. >>>>>>> >>>>>>> Marvin Humphrey >>>>>>> >>>>>>> --------------------------------------------------------------------- >>>>>>> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org >>>>>>> For additional commands, e-mail: general-h...@incubator.apache.org >>>>>>> >>>>> --------------------------------------------------------------------- >>>>> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org >>>>> For additional commands, e-mail: general-h...@incubator.apache.org >>>>> >>>> >>>> --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org >>>> For additional commands, e-mail: general-h...@incubator.apache.org >>>> >>>> >>>> >>>> >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org >> For additional commands, e-mail: general-h...@incubator.apache.org >> >> >> --------------------------------------------------------------------- To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
