Rockbox.org home
release
dev builds
extras
themes manual
wiki
device status forums
mailing lists
IRC bugs
patches
dev guide



Rockbox mail archive

Subject: Proposal - Rockbox Maintainers

Proposal - Rockbox Maintainers

From: Dave Chapman <dave_at_dchapman.com>
Date: Sun, 22 Jul 2007 16:13:22 +0100

Hi all,

I was wondering what other developers thought about introducing the
concept of formal maintainers to Rockbox.

A lot of large open source projects seem to work this well - an example
is the ffmpeg maintainers list here:

http://svn.mplayerhq.hu/ffmpeg/trunk/MAINTAINERS?view=co

I see a maintainer for a particular part of Rockbox as someone who is
capable of (and most importantly will make time to) investigating and
fix bug reports related to that section of the code, and also to review
patches (and commit them if and when the code is committable).

The ffmpeg list is very long, and I see a list for Rockbox as being a
similar size, if not longer. For example, each plugin would have a
maintainer, as would each codec. The apps/ code would be split into
many parts (menus, settings, playback, wps, database, playlists, etc),
as would the firmware/ code. We may even want to have maintainers for
each target supported by Rockbox (someone who uses that device every day
and can soon spot newly introduced bugs or test new features).

Informally, I think this already happens with many parts of Rockbox, but
this is mainly where the original author of the code in question is
still actively developing.

The problem IMO is those parts of Rockbox where the original author(s)
are not actively developing any more, or where the original author has
lost interest in that part of the code. This code then becomes
effectively unmaintained because no-one knows it well enough.

This is why I think having a formal list of maintainers would be useful
- so that we know which parts of Rockbox have active developers who are
interested and movitated to work on them, and more importantly, which do
not.

Speaking personally, I would be happy to start working on parts of
Rockbox that I'm not currently very familiar with, and would find a list
of "unmaintained" parts of the code useful in deciding where spending my
time would be most helpful to Rockbox in general.

That's really all I'm suggesting - that we try and organise ourselves
more efficiently. So instead of lots of people knowing a little about
everything, we each try to become expert in something, and hence become
more productive.

What do people think? Is anyone apart from me willing to commit to
maintaining certain parts of Rockbox? Or do people want to keep the
current informal "everyone is responsible for everything" approach?

Dave.
Received on 2007-07-22


Page was last modified "Jan 10 2012" The Rockbox Crew
aaa