Re: [Rhythmbox-devel] How hard is it to get attention from RB developers?

[Jonathan Matthew <jonathan kaolin wh9 net>]

On Sat, Aug 18, 2007 at 02:46:44PM +0800, Thomas Zander wrote:
> Good day,
> 
> I just wondered how long it usually takes between submitting a
> bugzilla report (including a fix for the problem) and a developer
> looking at it?

It depends so heavily on various factors that there's no real answer.
One thing I can tell you is that we really should be more responsive
than we are at the moment.  The list of 120+ unreviewed patches in
bugzilla is kind of intimidating, though..

> This is not intended to piss anyone off or to start a flame war. I
> know how busy developers are. It is just that, as far as I understand
> projects like this, contribution is a good thing, isn't it? And if you
> are literally waiting for months until (or if at all) someone with
> commit privileges chooses to talk to you about your patches, it's not
> easy to stay motivated in getting your code upstream.

I understand that it's frustrating, and I'm sorry for my part in that.

So, there are four main tasks that take up my rhythmbox hacking
time, which itself competes with various other leisure time activities:

- working on new features
- fixing existing bugs
- reviewing other people's patches
- processing the hundreds of crash report bugs

As it happens, they're listed more or less in order of how much fun I
find them to be.  One problem is that the last one gets in the way of
the middle two.

95%+ of the crash report bugs are either duplicates of a few
already-fixed bugs (434003, 436456, and 403801 currently) or have
useless stack traces, but we do need to dig through them all to find the
few that actually contain new and useful information.  If nothing else,
they clutter up bug lists and depress me.

In short: the more people help out with the bug-buddy pile, the more
time we have for better things.

> Or is there a different objective? Are we supposed to develop plugins
> but not touch the existing code base at all?

No, plugins are only appropriate for certain types of features.  It's
generally obvious when something can't be implemented as a plugin, and
it's also generally easy to convert something that isn't a plugin into
one.