On Thu, Aug 16, 2012 at 7:27 AM, drew <d...@baseanswers.com> wrote: > On Wed, 2012-08-15 at 18:06 -0700, Dave Fisher wrote: >> On Aug 15, 2012, at 5:37 PM, Rob Weir wrote: >> >> > On Wed, Aug 15, 2012 at 7:31 PM, TJ Frazier <tjfraz...@cfl.rr.com> wrote: >> >> On 8/15/2012 18:52, Rob Weir wrote: >> >>> >> >>> On Wed, Aug 15, 2012 at 5:45 PM, Dave Fisher <dave2w...@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. >> >> 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. >> >> 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. >> >> 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. >> >> Does that help? > > NO > > The ASF stands behind the actual binary release as official or not, it > is not a niggling point in my mind. What does that mean - it means that > a binary will be kept available (not just the source), it means that a > security fix is not released if it is in source only, for a package that > has been previously released in binary form, not as a convenience but > has a duty. >
Maybe a good way to look at this is: 1) Fundamental Apache principles include The Apache Way as well as the Apache License. Like any other open source license, ALv2 is grounded on copyright. Copyright is grounded on the creative expression of authors. So with computer programs this puts the source code (and documentation and art work) in a central position of importance. Our work to carefully track the source code, where it comes from, collecting iCLA's, adding NOTICE and LICENSE files, this is all geared to clarifying the copyright and license of the source code. The source code *is* the program. The source code is where the rights of users come from. This is true even for users who only touch the binaries. So as a project we always need to have a proper degree of respect for the source code, NOTICE and LICENSE, and associated build instructions that allow the project (and in this case the IPMC) to verify that the source code is complete. 2) The IPMC uses the term "canonical" to express the status of the source code in a release: "The source package is canonical. Every release must revolve around a source package. Compiled languages may also wish to create binary packages. These may be platform specific." I think "canonical" is a good term to use, accurate and unlikely to be misinterpreted or cause offense. 3) Referring to binaries as being for "mere convenience" expresses a developer- or admin-centric view that is appropriate for the majority of Apache projects. In those cases the binaries are for convenience only, since their audience of users has the requisite skills to build the software from source. A little reflection would suggest this is unlikely to be true for all projects and all users. Threshold question might be to ask whether your mother could build your project. Or a 10 year old in school. Or a public administrator. For OpenOffice, for millions of users, the binaries are not merely a convenience. 4) Similarly, "unofficial" might accurately reflect the status of binaries for some Apache projects. For example, Subversion does not issues official binaries at all. Instead they link to unofficial 3rd party distributions, ports, etc. We've talked about listing unofficial releases as well, e.g., for Solaris, OS/2, BSD, portableApps, etc. But this is a different beast. It is not the status of a release that is built, voted on and released by the project. I think it is important that we distinguish between common practice based on common circumstances and Apache policy. Not everything that other projects do is mandated by policy. Not everything that most or all other projects do is mandated by policy. Some things are merely conventional, based on circumstances, but where variation within policy is permissible. Being the first Apache project to have a predominately end-user audience means that we will need to continue to point out this distinction. Regards, -Rob > > > //drew >> >> Regards, >> Dave >> >> > >> > -Rob >> > >> >> (Sorry for no neat refs; I keep my own archives :-) ) >> >> /tj/ >> >> >> >>> >> >>>> (I really don't want to -1 this release.) >> >>>> >> >>>> Regards, >> >>>> Dave >> >>>> >> >>>>> >> >>>>> Thanks & Regards, >> >>>>> Dave >> >>>>> >> >>>>> >> >>>>> Begin forwarded message: >> >>>>> >> >>>>>> From: Jürgen Schmidt <jogischm...@gmail.com> >> >>>>>> Date: August 15, 2012 7:01:47 AM PDT >> >>>>>> To: "ooo-dev@incubator.apache.org" <ooo-dev@incubator.apache.org> >> >>>>>> Subject: Re: [VOTE]: Release Apache OpenOffice 3.4.1 (incubating), RC2 >> >>>>>> Reply-To: ooo-dev@incubator.apache.org >> >>>>>> delivered-to: mailing list ooo-dev@incubator.apache.org >> >>>>>> >> >>>>>> Hi, >> >>>>>> >> >>>>>> please vote on this email to ooo-dev only, thanks. >> >>>>>> >> >>>>>> On 8/15/12 2:02 PM, Jürgen Schmidt wrote: >> >>>>>>> >> >>>>>>> Hi all, >> >>>>>>> >> >>>>>>> this is a call for vote on releasing the following candidate as >> >>>>>>> Apache >> >>>>>>> OpenOffice 3.4.1 (incubating). This will be our first bug fix release >> >>>>>>> after the AOO 3.4 from May 8th. A further milestone to show that we >> >>>>>>> deliver good and stable software with focus on quality. It will again >> >>>>>>> help to continue the success of OpenOffice.org and will gain >> >>>>>>> confidence >> >>>>>>> in OpenOffice. >> >>>>>>> >> >>>>>>> This time I did not prepare a separate page to highlighting the >> >>>>>>> release >> >>>>>>> candidate. We had developer snapshot since several weeks and the >> >>>>>>> latest >> >>>>>>> one based on revision 1372282 is intended to become released if the >> >>>>>>> voting succeeds. That means and to make it clear you vote here on the >> >>>>>>> final release based on this snapshot build. >> >>>>>>> >> >>>>>>> >> >>>>>>> This release is intended to be a bug fix release and to introduce >> >>>>>>> some >> >>>>>>> further languages: >> >>>>>>> (1) 71 issues are fixed and a detailed list can be watched under >> >>>>>>> http://s.apache.org/Huv. >> >>>>>>> (2) 5 further languages are now officially supported: British >> >>>>>>> English, >> >>>>>>> Khmer, Slovenian, Slovak, and Finnish. >> >>>>>>> >> >>>>>>> For a detailed feature overview please see the release notes under >> >>>>>>> >> >>>>>>> https://cwiki.apache.org/confluence/display/OOOUSERS/AOO+3.4.1+Release+Notes. >> >>>>>>> >> >>>>>>> >> >>>>>>> The release candidate artifacts (source release, as well as binary >> >>>>>>> releases for 20 languages) and further information how to verify and >> >>>>>>> review Apache OpenOffice 3.4.1 (incubating) can be found on the >> >>>>>>> following wiki page: >> >>>>>>> >> >>>>>>> >> >>>>>>> hhttps://cwiki.apache.org/confluence/display/OOOUSERS/Development+Snapshot+Builds#DevelopmentSnapshotBuilds-AOO3.4.1 >> >>>>>>> >> >>>>>>> >> >>>>>>> Please vote on releasing this package as Apache OpenOffice 3.4.1 >> >>>>>>> (incubating). >> >>>>>>> >> >>>>>>> The vote starts now and will be open until: >> >>>>>>> >> >>>>>>> Saturday, 18 August: 2012-08-18 2:00pm UTC+2. >> >>>>>>> >> >>>>>>> After the vote of the PPMC the vote will start on >> >>>>>>> gene...@incubtor.apache.org mailing and will be open for further 72 >> >>>>>>> hours. >> >>>>>>> But we invite all people to vote (non binding) on this RC. We would >> >>>>>>> like >> >>>>>>> to provide a release that is supported by the majority of our project >> >>>>>>> members. >> >>>>>>> >> >>>>>>> [ ] +1 Release this package as Apache OpenOffice 3.4 (incubating) >> >>>>>>> [ ] 0 Don't care >> >>>>>>> [ ] -1 Do not release this package because... >> >>>>>>> >> >>>>>> >> >>>>> >> >>>> >> >>> >> >>> >> >> >> >> >> >> > >
