I don't know how you can QA and regression test any OpenOffice.org distro if you don't build it, and built it for multiple platforms. And you need the distro to be "as-built" (uh, not exactly how that term is used these days, but think of the reason uucp was invented) or it is all over but shooting the wounded.
I think it is essential to address the entire software-lifecycle *spiral* and its support for this beastie. I also think that this may be the fertile ground for harmony with LibreOffice. LibreOffice has a very strong and getting-stronger position on the customer-delivery and feedback side of this adventure. The cycle of learning and improvement has to come back through what gets developed (especially for bits sourced from Apache in the future) with as little friction as possible. Similarly, any refactoring and componentization of the Apache OpenOffice.org code base must not be without consideration for what LIbreOffice, as a significant consumer (let's say) needs in order to build what they want to deliver, including bits that will never be Apache's because that's how some LibreOffice committers (and users too) may want it. It seems to me there needs to be a joint meritocracy around orchestrating the interdependency of LibreOffice and relevant aspects of an Apache undertaking. I don't think that means a new custodian or another non-profit. We have two very transparent, open, and meritocratically-accountable organizations. I'm thinking of some sort of technical council whose burden is to shepherd the interdependency and the life-cycle concerns that go with it, but without custody of any code and operating entirely under the good will of the two organizations. An essential requirement is low friction, helping to avoid duplication and pointless deviation, and contribution to the sustained learning and improvement around the Apache <-> LibreOffice interdependency. I think the interdependency is real, though not the only one that may emerge, and we should move to cultivate and nurture it quickly. - Dennis PS: In my past lives, the answer to situations like this was market and customer forces compelling deviant solutions to align and avoid confronting anyone with a beta-vs-VHS situation. Sometime it meant alignment on a standard (though at one level, the document format, we have the basics of that here). But that was around competition among private parties (e.g., corporations and closed-product commercial offerings) and it was perhaps all that could be achieved. It seems to me that there is a different opportunity here and it is going to depend on developing trust and respect for the differences in organizational (and contributor) culture and that of adopters of the office-document software from either organization, as well. It will take real elbow grease and we probably need to quickly find the least that can possibly work -- for now. I also concede that we are looking at forks and what we need to secure for the mutual benefit of everyone is smoothness by which the common part can be maximized and embraced. -----Original Message----- From: Greg Stein [mailto:gst...@gmail.com] Sent: Friday, June 03, 2011 14:04 To: general@incubator.apache.org Subject: OO.o downloads on Day One (was: "opportunity to reunite the related communities" ...) On Fri, Jun 3, 2011 at 16:29, Simon Phipps <si...@webmink.com> wrote: >... > text in the wiki doesn't give that assurance. I'm also suggesting it's >/such/ a big deal for the open source community at large that >openoffice.org resolve to a working and current site without >interruption ... I don't think there is any immediate plan to take down openoffice.org or any of its subareas on Day One. It should continue to function normally. I honestly don't know what Oracle has said about this. Maybe somebody knows? Sam? Over time, we'll need to move that "in-house". Whether binary downloads do or not... up to the project. Historically, being a volunteer-based org with little access to a complete range of build targets, we've not distributed binaries[1]. Some volunteers build stuff and post that into our mirror network, but it is typically a convenience thing rather than "official policy". But with that said, it would be entirely reasonable for an Apache $name project to make it policy and acquire the necessary build farms to produce the releases. Cheers, -g [1] of course, Java projects build and post .jar files (or whatever); I'm talking about C/C++ apps like OO.o --------------------------------------------------------------------- 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
