On Tue, Jun 7, 2011 at 4:52 PM, William A. Rowe Jr. <wr...@rowe-clan.net> wrote: > 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
I don't believe this is true - we have to release the source, but anything we distribute is considered released and needs to be checked/approved - and the release FAQ seems to agree with that http://www.apache.org/dev/release.html#what Niall > 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 > > --------------------------------------------------------------------- To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
