On Aug 15, 2012, at 6:29 PM, Rob Weir wrote: > On Wed, Aug 15, 2012 at 9:06 PM, Dave Fisher <dave2w...@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 <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. >> > > 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. (2) Digitally signing binary artifacts mechanically by infrastructure from these build instructions. A requirement for apache.org certificates. (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 > > -Rob > >> 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... >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>>> >>>> >>>> >>
