Rockbox mail archiveSubject: Re: Handling NoDo features
Re: Handling NoDo features
From: Frank Gevaerts <frank_at_gevaerts.be>
Date: Mon, 29 Mar 2010 22:21:50 +0200
Ok, I think the discussion is mostly over, so I'll summarise what I
understand the consensus to be
On Tue, Mar 23, 2010 at 08:58:16PM +0100, Frank Gevaerts wrote:
> * Every single NoDo item *must* appear on http://www.rockbox.org/wiki/NoDo
Everyone seems to agree on this.
> * All NoDo items must have a proper rationale
I think everyone agreed that NoDo items without a stated reason are bad.
There's some disagreement about how strong such a reason should be
Personally I don't think this matters much. The stated reason isn't the
only thing (or even the main thing) that decides whether something
appears on the NoDo list. The main reasons why I want this rationale is
to make it easier to re-evaluate the NoDo decision later on, when nobody
remembers the details of the original discussion, or to explain to patch
authors why their work was or is going to be rejected.
> * All NoDo items must be reconfirmed once a year, possibly at DevCon
This was I think the least clear, but the good news is that we don't
have to have an answer to it anytime soon. We have one year to decide
whether or not we want this after the initial review of the NoDo list
is done. This should probably be discussed at DevCon.
I think we can move to the next step, which is to actually document all
existing NoDos on the wiki.
I've added a new section to the NoDo page listing some of the unwritten
NoDos I've noticed. I have not added a rationale, because I usually don't
know the detailed reasons for them. Please complete the list, so we can
discuss things properly at DevCon.
Please shout if I've added things that shouldn't be there.
I'd suggest that anything that is not on the list by the time DevCon
starts is not a NoDo.
-- "Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it." - Brian W. KernighanReceived on 2010-03-29