Rockbox mail archiveSubject: supported players
From: Frank Gevaerts <frank_at_gevaerts.be>
Date: Tue, 14 Jul 2009 22:30:18 +0200
At DevCon in Gent we decided to relax the requirements for a player to
be called "supported".
I've listened to the relevant bit of the recording, but I didn't hear a
clear conclusion, so here's what I remember. Feel free to jump in if you
remember something differently.
The meaning of "supported" would be something like:
* Runs rockbox and is usable as a normal music player
* There is a safe and well documented installation method for at least
one operating system, although of course more are preferred.
* There are released bootloader binaries, as well as binaries for
installation tools (if needed)
There would be a subset of this that implies more. There is no consensus
yet on how to call this group (although "gold" has been proposed), but
it would additionally require:
* rockbox runs well enough and has enough features to allow most people
to use it exclusively and not use the OF
* there is a manual. This was not seen as an excessive requirement
because it is not a requirement for "supported", only for "gold"
* all hardware in the player that is supported by rockbox works well
(there may still be hardware that is not supported, e.g. usb host)
* rbutil installation support is not required. It would of course be
nice to have.
The "gold" targets are also the ones that will be included in the
A target would enter "supported" state if the porters feel it is ready
for it. The list of supported targets on the front page (or wherever it
ends up) should have a list of the most important problems users can
expect with it, especially for non-gold targets
Some of this is pretty vague in my memory, so I might be confusing my
opinion and the consensus here and there. Please shout if you feel that
this is the case.
-- "Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it." - Brian W. KernighanReceived on 2009-07-14