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

[Christopher James Halse Rogers <raof ubuntu com>]

On Wed, Feb 3, 2010 at 8:31 AM, Bertrand Lorentz
<bertrand lorentz gmail com> wrote:
> On Mon, 2010-02-01 at 10:04 +1100, Christopher James Halse Rogers wrote:
>> 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:
>> >> 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.
>
> Thanks for sharing your experience !
> I don't see us reaching into the realm of 100 extension either, but I'd
> be happy to be proven wrong in the future. "A dozen Banshee extensions
> ought to be enough for anybody" ;)
>
> Out of curiosity, do you know how the GNOME Do plugins are going to be
> broken out ? By quality/support level (ala GStreamer good, bad and ugly)
> or by feature categories ?
> Any advice, technical or process-wise, is of course welcome ! :)

We're not certain yet.  Splitting out by quality/support would get us
back to the official/community plugins state, and I think that will
remain a bit unwieldy.  The biggest problem with the status quo is
that it's difficult to find what you want in the bugtracker when there
are a hundred plugins.  I think what we're likely to end up with is a
core plugin package that contains a small number well-tested, well
maintained plugins and then bundle the rest in logical groups - the
Google plugins, media player plugins, etc.

Process wise, Do was a bit strange.  We picked up a *lot* of
first-time contributors - one of our strengths is that it is really,
really easy to write a Do plugin.  A downside of this was that many of
our plugins ended up being drive-by contributions.  One of the
problems moving to a non-monolithic plugin set should help with is
reducing the maintenance burden on the core devs.  I don't think this
will be as much of a problem for Banshee, though.  There's a higher
technical bar for contributions because I think the scope of Banshee
extensions is much narrower.

Technically, I don't think Banshee will have a problem.  Do initially
used Mono.Addins incorrectly, requiring that a repository exist, and
this was awkward for distro packaging.  Banshee extensions can just be
dropped in the appropriate directory and work.