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
