From: Jonathan Gordon <jdgordy_at_gmail.com>
Date: Mon, 19 Dec 2011 09:18:20 +1100

On 19 December 2011 04:39, Thomas Martitz <kugel_at_rockbox.org> wrote:
> 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.

This pretty much sounds like a given, so once we move to git we create
a fork branch and start stripping crud out :)
Received on 2011-12-18