On 6/7/2011 10:23 AM, Phillip Rhodes wrote: > > One question about the comment above though: Are you advocating that Apache > OOo stick to source-only releases, and avoid > building and delivering binaries altogether? Or is your idea that Apache > OOo would deliver builds, but that they be "Vanilla OOo" , ala the "vanilla > kernel" from kernel.org, with a presumption that (some|most|all) end-users > will choose to use a distribution provided by somebody else... where > somebody else could be IBM, Novell, LibreOffice, Red Hat, etc.?
Just to clarify, only source code is "released" by the ASF. Yes, there may be binary artifacts built on that code (esp in the case of .jars), and some of the reviewers may choose to verify available binaries, and some may also verify their own binary builds, before voting on the release. Some|most|all end-users (by which I mean administrators and even developers using tools such as eclipse) obtain most Apache software as you describe above, from another party. In fact, RedHat might pick up the entire LibreOffice stack which in turn is derived from much shared OOo code, while a BSD distribution might pick up only the AL OOo base, and an entirely unrelated office productivity suite might pick only document manipulation classes from an AL OOo code base. As an observer to the CoApp project at OuterCurve, I'm particularly excited by what that project could accomplish with a Windows package, starting from the AL base, including the LibreOffice work in GPL/CC that the ASF would be unwilling to host. As an .msi based distribution which shakes out at the library/component level, upgrades from release to release might consume far less bandwidth. --------------------------------------------------------------------- To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
