From: Thomas Martitz <kugel_at_rockbox.org>
Date: Sun, 18 Dec 2011 18:39:37 +0100

Am 15.12.2011 00:21, schrieb Mike Giacomelli:
> 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.
>

I agree with forking out HWCODEC into a legacy series. It has many
advantages, while the only real advantage that keeping it in has (which
is that new features also apply to the eldest targets) is nullified if
the actual users don't upgrade.

HWCODEC, which includes CPU_SH and CHARCELL, largely unmaintained.
There's no active development, and it's basically only a PITA for the
active devs. The devs with HWCODEC targets aren't the active devs. In
the meantime people try hard just to keep the build table green. They do
this without the ability to test changes, as people with hwcodec targets
are often not reachable.

All this effort is useless if the users don't even upgrade. I wouldn't
want to force useless effort onto devs, possibly lowering the creativity
or rate of contributions.

Another advantage not mentioned yet is that getting HWCODEC out allows
for a big cleanup in the code base. Lots of the oldest and ugliest code
is only for one (or more) of the aforementioned characteristics
(hwcodec,sh,charcell).

I see little sense in trying to support (yes, we currently don't really
support it) hwcodec further. Removing the maintenance burden seems much
more appealing.

Best regards.
Received on 2011-12-18