incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jim Jagielski <>
Subject Re: [VOTE] Apache OpenOffice Community Graduation Vote
Date Mon, 27 Aug 2012 12:39:00 GMT
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 <> wrote:

> Exactly- just work within the constraints
> and there is no practical problem whatsoever.
>> ________________________________
>> From: Andrew Rist <>
>> To: 
>> 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
>>> 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 <>
>>>> 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 <>
>>>>>> 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 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
>>>>>>> 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
>>>>>> would expect that:
>>>>>> 1) It would come from the ASF Board, or from a Legal Affairs, not
>>>>>> 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
>>>>> 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
>>>>>>> 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
>>>>>>> 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:

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

View raw message