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".
>________________________________ > 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 > > > >
