Mailing-List: contact ooo-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: ooo-dev@incubator.apache.org
Received-SPF: pass (athena.apache.org: domain of jogischmidt@gmail.com
 designates 209.85.214.47 as permitted sender)
Message-ID: <502CAA3C.6000406@gmail.com>
Date: Thu, 16 Aug 2012 10:07:24 +0200
From: =?windows-1252?Q?J=FCrgen_Schmidt?= <jogischmidt@gmail.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7;
 rv:14.0) Gecko/20120713 Thunderbird/14.0
MIME-Version: 1.0
To: ooo-dev@incubator.apache.org
Subject: Re: [DISCUSS][VOTE]: Release Apache OpenOffice 3.4.1 (incubating),
 RC2
References: <502BABCB.9060308@gmail.com>
 <4468D2D6-6768-450D-B01F-D7D0EBD7A660@comcast.net>
 <C5D23C7D-E95F-4281-9E77-625FDA960C27@comcast.net>
 <CAP-ksoiPzYPzRuA7RWSoynKGUfLjTyHSLnMR76uW7DpXnqn-5Q@mail.gmail.com>
 <502C3166.7050303@cfl.rr.com>
 <CAP-ksohc1_=bh+QsduEBkYkgs7454Co4XH35xz19WomaYPqgWQ@mail.gmail.com>
 <BA2E456F-F2A4-422C-8BD8-0C19CE5CFB58@comcast.net>
 <CAP-ksogOzxOh7GgvJnP9hdTisD_Lns1XuPHXyoj6Ghqj7tigNg@mail.gmail.com>
 <2AE40AD6-5A6C-436C-A70D-DEB9A99A06B0@comcast.net>
In-Reply-To: <2AE40AD6-5A6C-436C-A70D-DEB9A99A06B0@comcast.net>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 8bit

On 8/16/12 5:08 AM, Dave Fisher wrote:
> 
> On Aug 15, 2012, at 6:29 PM, Rob Weir wrote:
> 
>> On Wed, Aug 15, 2012 at 9:06 PM, Dave Fisher <dave2wave@comcast.net> wrote:
>>>
>>> On Aug 15, 2012, at 5:37 PM, Rob Weir wrote:
>>>
>>>> On Wed, Aug 15, 2012 at 7:31 PM, TJ Frazier <tjfrazier@cfl.rr.com> wrote:
>>>>> On 8/15/2012 18:52, Rob Weir wrote:
>>>>>>
>>>>>> On Wed, Aug 15, 2012 at 5:45 PM, Dave Fisher <dave2wave@comcast.net>
>>>>>> wrote:
>>>>>>>
>>>>>>>
>>>>>>> On Aug 15, 2012, at 2:22 PM, Dave Fisher wrote:
>>>>>>>
>>>>>>>> Is there a reason that the README in the source release is still
>>>>>>>> pointing at http://wiki.openoffice.org/wiki/MacOSXBuildInstructions for Mac
>>>>>>>> Builds?
>>>>>>>>
>>>>>>>> Minimally this then points to http://wiki.openoffice.org/wiki/AquaBuild
>>>>>>>> this doesn't seem exactly like what was used for 3.4.0?
>>>>>>>>
>>>>>>>> Would someone check the Build instructions and then update to be very
>>>>>>>> clear what is current.
>>>>>>>>
>>>>>>>> I am proceeding with my tests as if the prerequisites have not changed
>>>>>>>> and that I have them from my AOO 3.4 tests build.
>>>>>>>
>>>>>>>
>>>>>>> I am stuck and I am stopping. I am very unhappy with the instructions on
>>>>>>> the WIki page. I needed help with 3.4 and now I need help with 3.4.1.
>>>>>>>
>>>>>>> Please show me the simplest way to build on a Mac from Source and show me
>>>>>>> on the Wiki based on http://wiki.openoffice.org/wiki/MacOSXBuildInstructions
>>>>>>>
>>>>>>> BTW - Remember that SOURCE is the ONLY OFFICIAL RELEASE.
>>>>>>>
>>>>>>
>>>>>> That is your opinion, expressed loudly;  it is not Apache or IPMC
>>>>>> policy.   We are officially voting on binaries as well and these are
>>>>>> being inspected and these will be part of the official release.  The
>>>>>> IPMC doc calls the source artifacts "canonical", but the same docs
>>>>>> talk about binaries being included in the official release as well.
>>>>>> In fact, it says of binary packages, "For some projects, this makes
>>>>>> sense. For others, it does not."  Obviously you have your own opinion
>>>>>> on this, but it is equally true that the vast majority of PPMC members
>>>>>> have a different opinion.
>>>>>>
>>>>>> -Rob
>>>>>
>>>>>
>>>>> Rob,
>>>>>
>>>>> Please consider the blistering email from Roy T. Fielding, to general@inc
>>>>> and to infra, on 3/27, 05:50, opposing "released' binaries. IMHO, he will
>>>>> need to change his mind. OTOH, he is a founder and board member ...
>>>>>
>>>>
>>>> Current IPMC policy, as documented, states otherwise.   ASF practice,
>>>> both with TLP's and Podlings, is to release binaries where the PMC
>>>> wishes to do so.  The general discussion has gone far beyond whether
>>>> or not we release binaries or whether they are official.  We're now
>>>> discussing how rather than whether these binaries can be signed.
>>>>
>>>> Availability of source code is what makes Apache OpenOffice open
>>>> source.  But the binaries are what make OpenOffice an end user
>>>> application, something no other Apache project has previously
>>>> attempted.  So it is not surprising that this is a challenge to
>>>> long-held practices and habits for some Apache members.  But this is
>>>> fully in accord with the Apache mission to publish software for the
>>>> public good.  I'd like to think that open minds can see how binaries
>>>> can be just as much of a public benefit as source code can be.  If
>>>> this is not apparent to anyone, I'd recommend a read of this page:
>>>>
>>>> http://incubator.apache.org/openofficeorg/mission.html
>>>>
>>>> So again I would ask that we choose our words more carefully, since
>>>> they are repeated, out of context, and are ascribed greater authority
>>>> than we might intend. For example, I read recently on a European
>>>> Commission websiste that a group of French agencies decided not to use
>>>> Apache OpenOffice, in part because they were lead to believe that
>>>> "Apache...doesn�t deliver installable software (binaries)".  This is
>>>> absolutely false.
>>>
>>> Convenience binary artifacts are released for the benefit of users.
>>>
>>
>> The phrase "convenience binary" does not exist anywhere on the IPMC website.
>>
>> What is said is "Many would argue that for open source projects, the
>> source package is the release: binaries are just for convenience."
>>
>> But "Many would say" does not a policy make.  The same page also says
>> of binaries, "For some projects, this makes sense. For others, it does
>> not."
>>
>>> At the most basic level when we VOTE we are approving the source release. We are stating that we understand the License and Copyright of the source and that it is in Policy. This is the standard for the IPMC and an Apache Member. It is not a vote that says that the code even works properly it confirms that it is valid Apache Release.
>>>
>>
>> The IPMC will be voting for the the release of source and binaries.
>> This includes verifying that the LICENSE and NOTICE in the binaries
>> are correct.  If you recall we had a delay in our first release due to
>> errors in these files in the binaries.  If we were not voting for
>> them, and if they were not official, then we would not have needed to
>> fix and rebuild before voting.  I've seen the same occur in other
>> projects, where the binaries where JAR's..  So even from the IPMC
>> perspective there are properties of the binaries that require
>> verification and which have policy implication.
>>
>>
>>> We, the PPMC, also VOTE that these binary artifacts are of high quality and that they work, but we are relying on others in the project to come up with that in aggregate - none of us have every environment - none of us understand every language. This is a different standard. We are certifying that the source release when built produces these artifacts and that they are useful to users.
>>>
>>
>> In the end a vote means what it says.  If the vote says we are voting
>> to release binaries as well as source then we are voting to release
>> both.  if anyone feels the wording of the vote violates IPMC or ASF
>> policy then they should object.
>>
>>
>>> We can consider how to treat the word "Official" or "Certified" around platform builds that may be called "Apache OpenOffice" as opposed to "Powered by Apache OpenOffice". This certainly gets into the area of digital signatures which is fast becoming a topic for multiple projects at The ASF. And yes the quality is about the control of the build.
>>>
>>
>> The only uses of  "official" and "unofficial" in the IPMC's release
>> documentation supports the view that our binaries are part of the
>> official release.
>>
>> IPMC and Branding policy does back up the view that downstream builds,
>> not built by or voted on by the PMC, and not distributed by Apache,
>> are "unofficial".  But that is not what we're dealing with here.
>>
>>> Does that help?
>>>
>>
>> I think I understand what you believe, but I don't think what you say
>> is an accurate reflection of current IPMC or ASF policy.  It appears
>> to me that you are inventing a new category of "unofficial release"
>> that has no basis in current documentation.  I'd recommend just
>> dropping that term, or working with the IPMC to get consensus on what
>> that means and what ramifications that has in terms of policy.  But as
>> far as I can see the binaries require the same review, the same vote
>> and the same distribution and signing requirements as the source.  So
>> inventing artificial categories, unsubstantiated by policy, will only
>> further alienate a community that is quite proud of the public good
>> brought by the binaries we have released for over 10 years prior to
>> Apache and which we have continued to do this this date, and be used
>> as FUD by those outside of the project.  I assume that is not your
>> intent, so best to just drop this.
> 
> This has been a good discussion. What I really want to address are three issues:
> 
> (1) Clear build instructions that can be mechanically verified that are part of the source release.

The build instructions can be always improved and we can of course do it
better. Especially consolidating the available information but all this
requires time and resources.

I have updated the linked wiki page to guide users to the current AOO
Building Guide that Andre has already mentioned.

The next step will be to update the README and link to the current
building guide.

Feedback how to improve the building guide is always welcome or simply
do it directly.

And of course if you have such huge problems why not simply starting a
new thread asking detailed questions and give feedback what exactly is
missing and what can be improved.

> 
> (2) Digitally signing binary artifacts mechanically by infrastructure from these build instructions. A requirement for apache.org certificates.

of course this will be added to the building guide when we know how the
final process will look like. We will probably have to tweak the process
a little bit because currently we use a pfx file containing the
certificate. By the way a very flexible way to exchange the certificate
on demand.

Juergen

> 
> (3) An Incubator and/or ASF policy that unambiguously describes what defines an official binary release.
> 
> (4) This might include a way that a third party like FreeBSD might certify a build as Apache OpenOffice.
> 
> But we don't need to do it here for 3.4.1. I'll likely take it up as a future when the VOTE goes to general@, but my VOTE won't depend on this build, this time.
> 
> Regards,
> Dave
>