>>>>> "FL" == Federico \"Lox\" Lucignano writes:
>> I also think that time might be better spent trying to get the >> plugins into SVN trunk. So please file enhancement bugs in >> bugzilla.gnome.org for any third-party plugins that don't already >> have one. If you create the plugin as a patch against SVN trunk, >> your chances of getting into SVN are much greater than just >> attaching a tarball that isn't integrated into the build system. FL> Some plug-ins will never make for SVN due to many factors, FL> e.g. they could be developed to address a specific problem of a FL> certain user (it's my case, just look at the plug-in I've released FL> recently on this list) or as an improvement/alternative to an FL> existing plug-in, they could be not as finished as required for FL> being released officially whith Rythmbox and so on. I'm not arguing that third-party plugins aren't useful or necessary in some cases. I'm just saying that there are many plugins that could usefully live in rhythmbox upstream SVN that with just a bit more work. e.g. the alarm clock plugin, the lastrhythm plugin. The problem with third-party plugins is that 1) they can be difficult to find for users and 2) don't integrate well with the native package manangement tool. Having them in SVN means that plugins get wider testing; they are more likely to stay in sync with the core code; they get l10n attention; and potential problems with plugins interfering with each other are much easier to spot. Again, that said, having a place for third-party plugins is fine, and I realise that not all plugins will reach the standard where they can be included in SVN. So if people want to create a place for them, that's fine too. I also realize that Launchpad isn't purely Ubuntu specific (my issue with Launchpad is that the code for Launchpad itself isn't open-source [this is also an issue with SourceForge.net]). FL> Just take a look at the list of available plug-ins/script for FL> Amarok released through KDE's extension manager ( FL> http://www.kde-apps.org/index.php?xcontentmode=56 ), how many of FL> those ones would be released officially with Amarok? Almost none, FL> since Amarok's devs know that users will be able to get any script FL> available on kde-apps through Amarok itself and plug-in developers FL> know that they have to publish their creations on kde-apps if they FL> want to share them. The same applies to Firefox/Thunderbird and FL> Opera (widgets) just to name a f This is slightly off-topic but point 2) is important when you want to deploy plugins system-wide, e.g. installing a plugin on my system (through rpm/yum or dkpg/apt-get) for all users obviates the need for each user installing the identical code in each of their directories. Although this is hard problem in general, I would like to see more third-party plugins systems, such as Firefox, OpenOffice.org etc. making a better effort to think about how plugins could interact with native package management systems rather than re-inventing an "plugin/extension managers" for every new application. FL> The "rush to SVN" is for adding new features to Rhythmbox through FL> a native implementation, not for plug-ins, there would be no point FL> in making available a plug-in system if users should wait for the FL> next big release of an app to use them. ;) Not so, most of the plugins in SVN rhythmbox are in Python, not in C. The plugin system also has uses besides allowing per-user third-party plugins (although that is obviously an advantage), e.g. distros can package each of the plugins in a separate subpackage (e.g. rhythmbox-daap, rhythmbox-lastfm) , to reduce runtime dependencies for the core rhythmbox app, as is done with gstreamer. Alex _______________________________________________ rhythmbox-devel mailing list [email protected] http://mail.gnome.org/mailman/listinfo/rhythmbox-devel
