gtg-user team mailing list archive

[Paulo Cabido <paulo.cabido@xxxxxxxxx>]

Hi!

Thanks for the support everyone! Nice to be part of the team!

Hope to keep up to everyone's expectations.
 
Sex, 2009-07-31 às 17:35 +1000, Jonathan Lange escreveu:
> 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

I kind of like jml's idea, a plugin can be a small thing or a
multi-person project, so it's not strictly necessary to be a bug in GTG
and authors are free to commit changes to their plugins and organize the
project the way they want (having to follow GTG's plugin guidelines).
But the other case can hapen also, a author may have dev access to gtg
to maintain his plugin.

My suggestions would be to think in the long term and compile the plugin
guidelines to GTG. We can start a draft on the wiki page.

> 
> _______________________________________________
> Mailing list: https://launchpad.net/~gtg-user
> Post to     : gtg-user@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~gtg-user
> More help   : https://help.launchpad.net/ListHelp

Paulo