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
audiences.
A.
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
<[email protected]> 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:
http://s.apache.org/H8J
http://s.apache.org/D16
http://community.apache.org/committers/
... 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
http://bizdev.openoffice.org/consultants.html) around the world to
become part of the community. I think we shouldn't ignore them,
Martin
- Sam Ruby
Martin
