Rockbox mail archiveSubject: Re: Release 3.7, freeze on monday
Re: Release 3.7, freeze on monday
From: Jonathan Gordon <jdgordy_at_gmail.com>
Date: Sat, 9 Oct 2010 23:02:46 +1100
On 9 October 2010 22:32, Dave Chapman <dave_at_dchapman.com> wrote:
> But my personal view is that features should only be added to Rockbox when
> there is a general concensus that it is a good idea. When 95% of devs don't
> express an opinion on a new feature, then I would read that as saying "we
> don't want it".
I don't really want to start this discussion again, but it always
keeps coming back anyway. This seems to be the cause of maybe 90% of
all arguments on the list. We really need to have a proper discussion
on how to get consensus/agreement from the (active) dev group.
COMMITERS has 134 lines, #rockbox has 139 users currently (most
idling), how are we supposed to ever commit anything without getting a
nod from every single person (even active ones, but then how do you
define when someone is active?)
The only logical way forward is continue to work how we do, unless
"enough" people are against a change there is a reasonable assumption
that the people not commenting don't care either way.
There are two more options we could take (both IMO would kill the project).
1) go the Linux route and have one/very few benevolent dictators
pulling changes as they want (means lots of forks and presumably a
boring upstream branch)
2) call a vote for every single feature, which is just ridiculous
considering the outcome of the RSB vote (30 commiters voted only..)
Doing this would almost certainly turn alot of people away because
sometimes a new feature can go from an idea to a commit in an evening
(r28206 for example) If that needed a vote then it almost certainly
would have been forgotten about by the time the "discussion" was
> Also, if only one or two devs are interested in a new feature, then that's going to mean that only those devs are going to be motivated enough to fix bugs in it. That's another reason features should be of general interest to the devs before being committed.
I don't entirely accept that argument because plenty of code currently
has no active dev. At least if someone is considered generally active
now there is a moderate chance he'll be around long enough to find
bugs, but eventually he will go. So does that mean we should never
accept any code?
Received on 2010-10-09