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: my comments on meeting1

Re: my comments on meeting1

From: Paul Louden <paulthenerd_at_gmail.com>
Date: Sun, 29 Jun 2008 01:51:44 -0500

Jonathan Gordon wrote:
> RSB - awesome... but whats the point of making the nominations
> private?
>
In case somebody wants to turn down their own nomination. The idea is
that Bob will say to Bagder "I nominate Joe." Then Bagder will go to Joe
and say "Do you want to run?" Joe can turn it down without knowing who
he's disappointing, or without 300 people knowing he turned it down. It
means more work for Bagder, but it makes sense in a way.
> just a reminder that I cant do anything about the sysfont splashes
> unless they are identified...
>
Might be nice to know, yeah. :)
> bookmarks.
>
The important fact from all that is that we want them to work
consistently (users don't have to care if a playlist is a file or
dynamic, or if they're bookmarking in a modified dynamic list, or if it
came from the database or not) rather than how exactly the consistency
should be accomplished. Further improvements to the UI itself, of
course, wouldn't be bad.
> viewports - it got a quick mention at the start about being one of the
> showstoppers (i.e the UI not being fully converted yet).. I'm not sure
> if its still a showstopper, but IMO it shouldnt be.
>
Didn't make it to the "release-blocker" list. In fact as long as all the
screens are usable, I don't think there's anything major here at all.
> "And all the plugin patches which noone seems to care about... (both
> patches to current plugins, and patches for new plugins)" - I added
> that one and you guys pretty much said what I was expecting... but one
> thing you might have missed... I was also talking about the patches to
> exsisting plugins which noone is currently maintaining... some are
> trivial patches and easy to check out, but some are not and you really
> need to know the plugin before commiting it. Do we give the patcher
> the benefit of doubt and assume the patch is good and correct and
> commit it?
>
>
I think this is a judgment call. We didn't discuss this, but I think it
depends on how complicated the patch is. If it's hard to
read/understand, it's hard to maintain, and we don't want plugins to be
unfixable if they break. At the same time, we don't want them rotting.
An important thing, though, is not just committing them because they've
been there for a while, in my personal opinion. Although I'm not
intending to point anyone specifically out, I would've personally
rejected the recent stopwatch patch over accepting it, with a preference
for asking for it to be rewritten to use the playback controls within
the stopwatch instead of trying to preserve the time across runs of the
program. Even if it works, I think there's still the question of "is
this a behaviour we want in the plugin?" But again, this is my personal
opinion on this matter.
> Jonathan
>
Received on 2008-06-29


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