incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dennis E. Hamilton" <>
Subject RE: OO.o downloads on Day One (was: "opportunity to reunite the related communities" ...)
Date Fri, 03 Jun 2011 22:49:24 GMT
I don't know how you can QA and regression test any 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 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 [] 
Sent: Friday, June 03, 2011 14:04
Subject: OO.o downloads on Day One (was: "opportunity to reunite the related communities"

On Fri, Jun 3, 2011 at 16:29, Simon Phipps <> 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  
> resolve to a working and current site without  
>interruption ...

I don't think there is any immediate plan to take down 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.


[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:
For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message