Once we release 0.8.2[1], it'll finally be easy to work with individual plugins, thanks to Alex's no-repo merge. I'd therefore like to suggest we split the monolithic do-plugins project into (a potentially large number of) multiple individual projects, under a "GNOME Do" meta-project. This will make it much easier for individual plugin authors to develop and release their plugins on a timeframe not bound to to the main GNOME Do release cycle.
I'd suggest that we keep an "official" plugins project, with the most
commonly used, useful, and well-maintained plugins in there. This may
or may not be all plugins currently marked as 'official'. I'd suggest
that all other plugins be split from this tree, probably into one
project per plugin or per logical plugin group (eg: the
g{Mail,Docs,Maps,etc} plugins probably belong together).
Pros:
*) This will reduce the barrier to entry for new plugins & plugin
authors
*) Plugin fixes can be pushed more easily, because they don't require
synchronising work with ~100 other plugins.
Cons:
*) There is no longer a single plugin tarball users need to grab. This
would likely be mitigated by distro packaging; I'd certainly be adding a
gnome-do-plugins-all metapackage to Ubuntu & Debian.
*) Plugin API breaks are less easy to manage, because there are more
stakeholders. We don't seem to be breaking API very often, so I don't
think this will be too much of a problem.
*) Less centralised control. We won't have the same assurance of
code-quality in plugins. I don't think this is really an issue,
although it may expose more core bugs.
[1] Which, assuming I can get the Flickr plugin to build with Karmic's
Mono 2.4, should be today.
signature.asc
Description: This is a digitally signed message part
