incubator-ooo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrew Rist <>
Subject Re: [discuss] remove of binfilter module
Date Wed, 15 Jun 2011 19:06:53 GMT
One approach we might look at here is to take this into consideration as 
we create the build system.
If pieces of OpenOffice that are in question can be either included (or 
excluded) through the build process,
different users of the code can make different decisions.
I can see justification for both decisions in terms of the document filters:
  - one build that tries to be barebones and only includes filters for 
high usage document formats  (*** maybe with the ability to add filters 
on demand from the cloud??? hmmm...)
  - another build that includes all of the filters ever made (the 
rosetta stone for documents)

In a similar way, I could see distributions limiting themselves to 
Write, Impress, and Calc, for instance , creating a smaller build with 
no Java dependency.

I think by properly structuring our build system, we can avoid forcing 
these types of decisions, while also opening up the possibility of 
multiple options in terms of packaging up the product to suite different 


On 6/15/2011 11:50 AM, Martin Hollmichel wrote:
> On 06/15/2011 07:59 PM, Sam Ruby wrote:
>> On Wed, Jun 15, 2011 at 1:17 PM, Martin Hollmichel
>> <>  wrote:
>>> On 06/15/2011 12:45 AM, Raphael Bircher wrote:
>>>> Am 15.06.11 00:15, schrieb Ivo Hinkelmann:
>>>>> Hi Christian,
>>>>> good idea to remove it, preferred the whole module. It saves us a lot
>>>>> of build time!
>>>> Build time no matters in this case. No user will understand this
>>>> argument. And the question is for wath we are here. To make a good
>>>> product for end user, or to play around with code?
>>> this raises a good question: how to make Product Management decisions ?
>>> The past has shown, that decisions driven by one main contributor are
>>> not necessarily the best ones. I'm wondering how can we establish
>>> something like a voting system for doing the right or at least good
>>> decisions. I also think, the one contributor - one vote thing also don't
>>> work out in this user centric matter (I think it will work well for
>>> engineering centric questions). We need something to identify good
>>> representatives of user communities to be able to do good decisions.
>>>> As QA I can't accept to remove samething to save Build Time, sorry.
>>>> Byside you can dissable binfilters if you build samething who does not
>>>> afffect the binfilter.
>>> It's important to bring the interests of all groups, engineering, QA,
>>> marketing and users to a common ground. This raises also the question
>>> which priorities are driven by whom, and how they get represented by whom,
>> Short answer: don't vote!  Yes, we want to include everybody!
> I canot agreed more, ...
>> Here's a few links:
> ... but these links don't really help me, since the OOo community and
> it's ecosystem(s) are much more than committers.
> The main objective is to bring as many developers as possible into the
> projects, many small and some big players in the Ooo market are able to
> do this. The key is, how do we listen to all the small players in the
> OOo market to enable them to contribute to OOo via committers ?
> There are now a few big ones (IBM, SuSe, Redhat, RedOffice, etc) in the
> arena, but how will we enable the thousands of small catalysts (see
> around the world to
> become part of the community. I think we shouldn't ignore them,
>>> Martin
>> - Sam Ruby
> Martin

View raw message