Date: prev next · Thread: first prev next last
2010 Archives by date, by thread · List index


----- Original Message ----

From: Charles Marcus <CMarcus@Media-Brokers.com>
On 2010-11-30 5:29 PM, BRM wrote:
LibO - like OOo - does not really  have separate components. Even  if you
could download just  one component, the resulting size would only be  a
few MBs  smaller than it is now.
While that may currently be the case - that is  absolutely ridiculous.
TDF/LO should make a priority of resolving that  issue.

Great, then I'm sure your contribution of these code changes will  be
forthcoming soon?

Yes, I'm joking.


As joking as you may be, I for one would do so if I had the time.
As it is - I might in a few months, but I can't guarantee it right now.

The cost/benefit would _be_ worth it.

As was explained to me -  it is not just that it is a huge job, it is a
monstrous job that would  essentially require rewriting the entire code
base from scratch. I have also  heard horror stories from very
experienced programmers when they start  getting into the code.


And that is exactly why it would be worth it. If experienced developers are 
having trouble
getting into the code, then just imagine how much the code itself is turning 
people away
from contributing to LO/OOo. Resolve that and you will likely get a lot more 
contributors
of varying experience levels - or at least, more experienced contributors.

So, again, no one is saying this wouldn't be a  wonderful thing, it is
simply not something that is feasible at the  moment.

It will never be feasible. So instead of saying "yeah that needs to be done, but 
its not feasible" let's hash out a plan for actually doing so.
 
Having created installers before - namely MSI's - there  should 
ultimately be no reason why the installer should be broken down  as:

- core LO libraries used by each package

And again,  the point is, these core LO libraries used by each (assuming
you mean  used/shared by all packages) consist of 98% of the size of the
download,

I mean:

- static and shared libraries that consist of code utilized by independent 
executables for each program.
- ancillary programs that aid each program
- etc.

 so  the cost/benefit ratio is just not worth it.

And again - you made my exact point that the cost/benefit will be worth it if 
not for getting more contributors alone.

Please stop discouraging this kind of work. If the effort is to be done at all, 
then we need to encourage this kind
of work - even if in small incremental steps. But it has to start somewhere and 
with a goal in mind to accomplish.

Are the LO/OOo developers/management that averse to change? I certainly hope 
not.
Is TDF that adverse to change? I certainly hope not as well.

Ben



-- 
Unsubscribe instructions: E-mail to discuss+help@documentfoundation.org
Archive: http://www.documentfoundation.org/lists/discuss/
*** All posts to this list are publicly archived for eternity ***

Context


Privacy Policy | Impressum (Legal Info) | Copyright information: Unless otherwise specified, all text and images on this website are licensed under the Creative Commons Attribution-Share Alike 3.0 License. This does not include the source code of LibreOffice, which is licensed under the Mozilla Public License (MPLv2). "LibreOffice" and "The Document Foundation" are registered trademarks of their corresponding registered owners or are in actual use as trademarks in one or more countries. Their respective logos and icons are also subject to international copyright laws. Use thereof is explained in our trademark policy.