From: Rafaël Carré <funman_at_videolan.org>
Date: Wed, 14 Dec 2011 18:58:48 -0500

Hello,

Le Wed, 14 Dec 2011 18:21:42 -0500,
Mike Giacomelli <giac2000_at_hotmail.com> a écrit :

> Hi everyone.
>
> Over the last couple months there has been some discussion about what
> to do with HWCODEC following dreamlayer's forum thread. During this
> discussion, several developers still using HWCODEC mentioned that they
> preferred/recommended older builds over newer releases. The general
> opinion seemed to be that somewhere around 2.x-3.0 HWCODEC peaked.
>
> Over the years we've discussed the possibility of forking off HWCODEC
> and decided that there are serious advantages and drawbacks to doing
> so. I'll list the ones that I remember (but I'm sure I'll forget
> some).
>
> Advantages:
>
> ***Greatly simplify large parts of the code for SWCODEC targets (see
> JdGordon's forum posts in rockbox general)
>
> ***Enable us to arrest and hopefully reverse the slow bin size
> increases that are squeezing HWCODEC to death by simplifying bits of
> rockbox that are simply too awkward to do with ifdefs.
>
> ***Prevent developers unfamiliar with HWCODEC from breaking it.
>
>
> Disadvantages:
>
> ***Only a few people are working on HWCODEC, so if we did fork it,
> would it just continue to rot?

There are still active developers working on HWCODEC models, so I don't
think bitrot will happen.

> ***Duplication of effort for fixes in common code

It can be made less painful with git cherry-pick to replicate fixes
between branches or even different remote repositories.

> ***HWCODEC is useful because it reminds us to avoid needlessly
> bloating file size (although this is probably no longer true since we
> have SWCODEC targets with more memory constraints)

Yeah and there is also the AMS bootloader constraint, it needs to fit
(once compressed) in a few hundred kilobytes to be patched by the OF.

> Over the years I think the advantages have become more appealing
> because its becoming harder and harder to keep binsize small enough to
> fit into some HWCODEC targets. While at the same time, we've got low
> memory SWCODEC targets that are arguably more constrained by total RAM
> (e.g. the c200v2 with 2.3MB of RAM for SWCODEC and a color display)
> then the Archos Player.
>
> I think we should consider branching into rockbox and rockbox-classic
> branches at some convenient point in the future.
>
> When we do, I propose that we would leave SWCODEC in the classic
> branch and setup the build system to compile a representative subset
> of those devices. From then on new features would focus on HWCODEC,
> and if someone is interested they would be free to pare back features
> like theming that consume binary space without being terribly useful
> on charcell devices.
>
> The non-classic branch would depreciate HWCODEC support. We would
> remove HWCODEC devices from the build system and gradually begin
> removing it from the code organically as various parts of rockbox are
> improved/refactored/rewritten.
>
> So in effect we would have one branch that gradually became SWCODEC
> only, and another branch that retained both, but would gradually be
> slimmed down for devices with ~ 2MB of RAM (that is HWCODEC devices or
> for that matter people who wanted a lower memory foot print SWCODEC
> build).
>
> 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.
>
>
> Thoughts?

I approve branching,

Although it seems trunk wouldn't be the more appropriate point for
branching since people prefer to run much older code (before 3.0).

Can't really comment on that as I never used the targets.

-- 
Rafaël Carré

Received on 2011-12-15