[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gnash-dev] What's in a Dictator?

From: Rob Savoye
Subject: Re: [Gnash-dev] What's in a Dictator?
Date: Fri, 25 Mar 2011 18:20:48 -0600
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv: Gecko/20101209 Fedora/3.1.7-0.35.b3pre.fc13 Lightning/1.0b2 Thunderbird/3.1.7

On 03/24/11 14:40, address@hidden wrote:

  I really, really, really do *not* want this to bloom into another
flame war. Flame wars are counter productive, and we all have work to do.

> Considering the size of Gnash itself, I have a hard time believing that
> the toolkit really makes much of a difference...

  Every little bit counts when working on a small system.

> I also wonder whether SDL+custom widgets really saves much compared to a
> full-blown toolkit.

  But SDL truly sucks, and I think we all agree on that. And yes, not
using QT does save critical space on a small system. I've ported Gnash
to many small embedded systems, I'm the only Gnash developer that works
on those platforms.

> I don't see a problem there. These things are orthogonal. Doing less
> refactoring doesn't mean Gnash will magically begin to move forward...

  My point was we all have limited time, so where we put it is
important. While stability and performance improvements also move Gnash
forward some, there are many new features we could be adding but don't.

> Only as far as necessary to prevent inconsistent features or crappy code
> entering the main tree.

  As a long time GNU project maintainer (since long before Gnash), I'd
disagree that is the sum total of responsibilities.

> As maintainer, you are by definition the dictator as regards to the
> official code base. It's up to you to reject changes you consider
> harmful. (But it's up to the others to fork or abandon the project if
> they think your decisions lack justification...)

  Without trying to start a flame war, many of the issues are from me
*not* rejecting changes that I should have. Course that would have
started a flame war anyway. Part of the problem is people rejecting my
own code from Gnash, that I have a major problem with. When there is a
disagreement of whether code should be rejected or not, somebody has to
decide, and that's a maintainers responsibility. The problem is the
people that disagree with that decision get pissed off and call me a
dictator, and then we find it hard to work together for awhile.

  I do not want to start a flame war, I'm just trying to give you an
honest answer.

> While you can certainly deny people from checking in certain changes,
> you can not make them work on other things instead. That's just not in
> your power.

  At one time I was funding all the Gnash developers, and even then
never told people what to do. I'm not sure why you seem to think I do
assign tasks. For Gnash, all developers pick their own tasks. Mind you,
when I was paying people to work on Gnash it would have been nice to
have more of a assigned task focus, but we never did that.

  The refusal of developers to want to do assigned tasks is a big reason
why funding dried up. People that donate money often want to see
something fixed or implemented. Since it was obvious nobody would do
anything I could have assigned to them, often the promised donations
wouldn't then happen. So now we have no money, and everyone can do what
they want without me stressing about it. Sad but true.

> Sometimes I get the impression that you'd prefer to work on Gnash alone.
> If so, it would save everyone a lot of pain if you just stated so
> directly.

  I really don't want to start a flame war, but why you think this I
have no idea. I've worked on team projects most of my career (several
decades), and like the community aspect of free software projects. I do
many other community oriented things in my life, and definitely do not
want Gnash as a solo project. It's funny you say this, cause I feel some
of the other Gnash developers would prefer to work alone, or at least
not have me contributing to the project I started.

        - rob -

reply via email to

[Prev in Thread] Current Thread [Next in Thread]