Rockbox.org home
release
dev builds
extras
themes manual
wiki
device status forums
mailing lists
IRC bugs
patches
dev guide



Rockbox mail archive

Subject: Re: Release 3.7, freeze on monday

Re: Release 3.7, freeze on monday

From: Frank Gevaerts <frank_at_gevaerts.be>
Date: Mon, 11 Oct 2010 20:33:21 +0200

On Mon, Oct 11, 2010 at 01:22:21PM -0400, David Hall wrote:
>
> All "new feature" commits (the earlier discussed metric of "changes
> user-seen behavior to the level of needing a manual modification" is
> dandy) should be posted to flyspray (where the yays and nays can have it
> out) for at least one week prior to commit?

What I'm worrying about is apathy. If we have such a rule, we'll have
one "vote" a week, or something in that order of magintude I guess.

Some of those won't have any problem reaching the required two or three
voters (depending on the version of the proposal), but I'm not at all
convinced that people will bother to go and agree that they'll be able
to ignore some new obscure plugin. So I really want some sort of system
to handle the case of "*really* nobody care".

One possible (partial) solution could be to have an exception for new
plugins, provided they can live with the existing plugin API. This
wouldn't solve the problem for any other change though.

Another solution could be to allow changes if the proposer follows all
the rules nicely (X days on flyspray, ask on ML every Y hours, whatever)
and the required number of yes votes is not reached (provided of course
that there are no no votes)

Frank

-- 
"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. Kernighan
Received on 2010-10-11

Page was last modified "Jan 10 2012" The Rockbox Crew
aaa