Re: [Banshee-List] Combining Unofficial Banshee Extensions [was: List of third party extensions on the website]

[Christopher James Halse Rogers <raof ubuntu com>]

On Sun, Jan 31, 2010 at 7:55 AM, Gabriel Burt <gabriel burt gmail com> wrote:
> On Sat, Jan 30, 2010 at 10:03 AM, Chow Loong Jin <hyperair gmail com> wrote:
>> On Saturday 30,January,2010 11:44 PM, Bertrand Lorentz wrote:
>>> On Fri, 2010-01-29 at 16:00 -0800, Kristopher Dick wrote:
>>>>       * https://launchpad.net/banshee-remote-plugin/1.0/1.0  Allows
>>>>         remote control of Banshee via the BansheeRemote app on Android
>>>>         phones.
>>>>       * https://launchpad.net/banshee-listening-post/smtp/1.0
>>>>          Provides the basic functionality of sending e-mail messages
>>>>         to a preconfigured recipient when the track changes.
>>>
>>> Cool, I didn't know about those two, thanks !
>>> I added them to the page, and I also added the "Radio Station Fetcher"
>>> and "Stream Ripper" extensions that I missed before.
>>
>> Cool, we have more extensions now!
>>
>> Since we've got a significant number of extension packages that need to be
>> transitioned every other Banshee release, I'd actually like to propose everyone
>> getting together and merging all the off-tree extensions into a single
>> code-base, and synchronizing releases with Banshee's release, in something like
>> an extension pack of sorts. In fact, I think the banshee-unofficial-plugins
>> project on Google Code was started with something like that in mind.
>>
>> This would make package maintainers' jobs (like mine, among others) much easier
>> -- no need to maintain separate packaging trees for each extension. To give an
>> idea on the volume -- if we have 10 different packaged extensions, and say, 3
>> versions of a distro that we want to backport the version to, that's 30
>> different packaging trees we have to maintain. And all of these have to be
>> transitioned every time a new Banshee release which breaks API/ABI appears. *cringe*
>>
>> There will also be benefits to the maintainers of each extension, of course. The
>> most clear of these would be that each extension maintainer will not have to
>> maintain his/her own entire Autohell (or other, probably inferior) build system.
>> Last I checked, Banshee.CoverFlow has no build system, for instance. With a
>> combined project around, it should be trivial to integrate a new extension into
>> the tree, similar to how it can be integrated into the current Banshee tree.
>>
>> What do the extension maintainers think? I'd like very much to hear from all of you.
>
> I think this is a good idea.  Gnome Do does this, with their
> gnome-do-plugins repo/package.  They also distinguish between
> Community plugins and Official ones.  I think this repo should be
> hosted in git, using gitorious.org as the primary repo, so people can
> clone/maintain it easily.  If you want to write a Banshee extension,
> just make an account there, clone the banshee-community-extensions
> project, run a script to create a new skeleton extension, and start
> coding!  Bertrand, what do you think of moving to git hosting?

It's probably worth noting that GNOME Do is planning to break out the
monolithic gnome-do-plugins branch into smaller pieces.  We've got
nearly 100 plugins in there, and it has become a bit difficult to
actually track bugs properly - particularly since the plugins see
wildly different levels of maintainer interest.

We're also going to remove the community/official distinction; it's
not very useful.  It doesn't change the level of bugs, and only serves
to make the plugin UI slightly more cluttered than it needs to be.

This isn't going to be an immediate problem for Banshee, and may not
be at any point - there's more scope for Do plugins than for Banshee
extensions, I think - but is worth contemplating, if only to decide
that it's not going to be a problem.