Rockbox mail archiveSubject: Re: Handling NoDo features
Re: Handling NoDo features
From: Gareth Schakel <gareth7yo_at_gmail.com>
Date: Tue, 23 Mar 2010 23:58:48 -0400
On 3/23/2010 8:35 PM, Jonathan Gordon wrote:
> On 24 March 2010 11:17, Dave Chapman<dave_at_dchapman.com> wrote:
>> I agree that giving a rationale for some no-do items is going to be very
>> hard - especially when Rockbox runs on such a wide range of hardware. A
>> feature that uses 100KB of RAM is obviously unlikely to be acceptable on 2MB
>> targets, but will have far less impact our 64MB targets.
>> In my view, binsize shouldn't generally be used as an argument against new
>> features. Instead, the argument should be that we don't want the added
>> complication to the code. Often these two go hand in hand.
>> But having said that, I fully agree with Frank's proposal - the barrier to
>> entry of the "no-do" list should be high, the reasons transparent, and the
>> collective opnions of developers on the no-do items should be sought
>> regularly (devcon seems ideal).
> Pretty much my feelings also, bin/RAM usage should never be the sole
> argument against something.
> I also feel that almost nothing should be NoDo unless it is actually
> technically out of the question.
I ussually just sit back and watch the lists, but something i want to
bring up: has anything ever been taken /off /the NoDO? if so, why? what
changed that allowed something that "couldn't" exist one day, be
possible the next? If not, what's *really* forcing the devs against
doing it? (im not saying anyone's lazy, at all, everyone in COMMITERS
deserves a pat on the back.) anyway, just thought Id'e bring that to light.
Received on 2010-03-24