> ***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. > Although I've successfully avoided to mess with HWCODEC, I feel it's a bit of a nightmare to deal with it without being to test it. Not to talk about the great deal of #ifdef code everywhere. > > Disadvantages: > > ***Only a few people are working on HWCODEC, so if we did fork it, > would it just continue to rot? > There is a possibility for this. However I think rockbox on these targets is really stable, there is no need to be "at HEAD" to have a great player. > > ***Duplication of effort for fixes in common code > Already replied, only major fixes would go there anyway. > > ***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) > I do not quite agree. Apart from the slow rising bin size here and there, the big steps were caused by functionality useless on HWCODEC mostly (UI, corealloc, others ?) and it will continue this way. We don't want to stop progress because some target doesn't have enough memory. > > > 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'm in favor of branching and backporting only really important fixes or functionality. I don't like the rockbox-classic namr thougn, it's confusing. It would prefer something like rockbox-legacy or rockbox-lite ? > > Michael >
