|
Rockbox mail archiveSubject: Re: HWCODECRe: HWCODEC
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 Page template was last modified "Tue Sep 7 00:00:02 2021" The Rockbox Crew -- Privacy Policy |