← Back to team overview

gtg-user team mailing list archive

Re: Rise of the plugins

 

On Fri, Jul 31, 2009 at 2:27 AM, Lionel Dricot<ploum@xxxxxxxxx> wrote:
> Hello everyone,
>
> Today is a big day for GTG as it saw the landing of the plugin engine done
> by Paulo Cabido, our SoC student.
>

Congratulations!

> It means that you can start right now to write your own plugin for GTG.
>
> Kevin Mehall didn't wait for us and already submitted a hamster plugin
> which integrates with the hamster-applet time-tracker. This plugin will
> only work with hamster 2.27 so I wasn't able to test it. Please report
> bugs and assign them to Kevin.
>

Hooray. :)

> A new question then appeared : what will we do with plugin authors ? We
> want to help author to easily maintain their plugins, we want to
> centralize ressources (bug tracker, release management) but we realize
> that we cannot just give full dev access to every plugin author. We also
> foresee that plugins will sometimes very specific.
>

Why do you want plugin authors to release in the same way that GTG releases?

> So, how do you propose that we handle this situation ? What are other
> projects doing ?
>

The Bazaar project has a convention of plugins having project names
like 'bzr-foo' (e.g. bzr-svn, bzr-pipelines). The way the bzr plugin
system works, the plugins don't have to be in the same branch as the
main application (maybe GTG plugins are like this -- I got to this
email before I could check out the feature).

This makes a fair bit of sense, since a bug in a plugin isn't
necessarily a bug in GTG. Also, Launchpad's bug tracker has a very
nice feature where a single bug can be marked as affecting multiple
projects. This could well be all you need for tracking bugs.

jml



Follow ups

References