incubator-ooo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joe Schaefer <>
Subject Re: [discuss] remove of binfilter module
Date Wed, 15 Jun 2011 19:18:09 GMT
----- Original Message ----

> From: Martin Hollmichel <>
> To:
> Sent: Wed, June 15, 2011 2:50:46 PM
> Subject: Re: [discuss] remove of binfilter module
> 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.

At the ASF being a committer takes on a more general meaning than simply
being another code developer.  There are lots of ways to contribute meaningfully
to the non-coding aspects of a project in areas of the ASF that are only 
to people with committer karma.

> 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, 

The primary focus at this particular point in incubation is to create enough
effective "feedback loops" so we can say the project has the ability to 
construct a 

self-sustaining development community.  (The "dev" in
is short for development, not developer.  There are lots of additional 
roles in a project of this size than the traditional coding role of a 

Since much of the basic infrastructure of the project is already operational
on the site, we can continue to use that as additional resources
come on line at the ASF.  Over the course of incubation I trust we'll be able to
migrate all of the "collaborative" services to ASF hardware, so things will only
improve over time.

But to Sam's earlier point, it's up to the people on this dev list to drive
and steer the overall activity thru consensus.  At some point mentors will try
to take a back seat and let the community take full control over its destiny.

View raw message