incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrew Rist <>
Subject Re: [VOTE] Apache OpenOffice Community Graduation Vote
Date Fri, 24 Aug 2012 18:44:24 GMT

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


Binaries created /from /the Official Release?
>> ________________________________
>> From: Dave Fisher <>
>> To:
>> 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 <> wrote:
>>>> On Fri, Aug 24, 2012 at 12:32 PM, Marvin Humphrey
>>>> <> wrote:
>>>>> Returning to this topic after an intermission...
>>>>> On Tue, Aug 21, 2012 at 6:18 AM, Bertrand Delacretaz
>>>>> <> wrote:
>>>>>> On Tue, Aug 21, 2012 at 11:54 AM, J├╝rgen Schmidt <>
>>>>>>> ...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
>>>>>>> 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
>>>>>> moment ASF releases consist of source code, not binaries.
>>>>> My impression from this discussion is that many podling contributors
>>>>> dismayed by this policy, and that there is an element within the PPMC
>>>>> 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
>>>>>> 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
>>>>> podling graduates, AOO binaries will once again be advertised as official,
>>>>> placing the project in conflict with ASF-wide policy.  It may be that
>>>>> 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
>>>>> 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:
>>>>> For additional commands, e-mail:
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail:
>>> For additional commands, e-mail:
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail:
>> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message