From: Boris Gjenero <boris.gjenero_at_gmail.com>
Date: Wed, 14 Dec 2011 20:50:50 -0500

Apparently, there are few HWCODEC users, and I'm not sure if any
developers regularly use current builds on HWCODEC targets. Because of
that, there isn't much focus on improving things for HWCODEC.

Developers have done an impressive job keeping HWCODEC functional while
making large changes. However, some of those changes increase binary
size without really benefiting HWCODEC targets. For example, look at
http://www.rockbox.org/wiki/MajorChanges . Except for new plugins, what
are the benefits to HWCODEC? Meanwhile, binary size and memory usage
increased, and RomBox became impossible on some targets.

The lack of users also makes it difficult to find and deal with HWCODEC
bugs. They can go unnoticed for a while, and where there's a fix, there
may not be anyone willing to test it. For example, I think FS#7960 has
been fixed, and the charging screen works properly on all except the V2
and FM Recorder (FS#7631), but nobody is confirming that.

I think the main disadvantage is:

> ***Only a few people are working on HWCODEC, so if we did fork it,
> would it just continue to rot?

I think some of the ideas for a HWCODEC branch might be too big. For
example, removal of theming requires replacement code which draws what
would otherwise be created via theming. How much interest is there in
doing work like this?

> The alternative I think is to keep both together indefinitely while
> accepting that people may not want to upgrade from what they're
> already running. I think this is a bad way forward because in
> practice if people do not upgrade, then we have left HWCODEC
> essentially unmaintained. People would basically be stuck with
> whatever bugs were built into the release or build they decide to stay
> with.

If developers want to retain HWCODEC support in the trunk, I can't
complain about that. However, if the latest version is not the best
choice, users should be told that. Also, in that case, the older version
they're directed to should at least get bug fixes. That's the essence of
my argument for a fork.

I don't mean to force the issue. I realize others have been far more
involved in Rockbox, and I'm okay with whatever is decided.

Regards,

Boris
Received on 2011-12-15