Shipping plugins (was: Re: Release testing and the relationship between 'bzr selftest' and plugins)

[Jelmer Vernooij]

On Thu, Mar 15, 2012 at 04:11:31PM +0100, Vincent Ladeuil wrote:
> >>>>> Jelmer Vernooij <jelmer at samba.org> writes:
> 
> <snip/>
> 
>     >> 1 - merge plugins into core, making them core plugins: we've talked
>     >> about that long ago but nothing happened. The main benefit is that
>     >> such plugins will be better maintained since a change in core will
>     >> be noticed more quickly. This add maintenance costs to bzr core
>     >> which is mitigated by less efforts on compatibility in both bzrlib
>     >> and the plugins.
> 
>     > I think this is just one of the ways we can make sure that the plugin
>     > tests get run often during development. But it's not the only way to
>     > make sure changes to the core are tested against the plugins.
> 
> Indeed, I wasn't implying anything else ;)
> 
>     > Shipping the plugins with core also has a few issues:
> 
>     >  * lp:bzr  (AFAIK) falls under the contributor agreement, and all code
>     > (with some exceptions) is (C) Canonical. Most plugins have different
>     > copyright holders.
> 
> Hmm, this one is hard.
> 
>     >  * shipping plugins implies a certain level of support for them
> 
> Yup, the balance may not be easy to find between time spent ensuring
> backward compatibility in bzr-core, compatibility with various bzr
> versions in the plugin itself and packaging the right versions as
> opposed to a single code base.
> 
>     >  * plugins can have dependencies - would we start shipping the svn, apr
>     > and mercurial sourcecode with bzr?
>     >  * some plugins have a different landing mechanism than bzr.dev;
>     > requiring review, for example
> 
> I'd say soft dependencies in bzr-core and build dependencies for
> packages or is should that be recommendations instead ?
> 
>     > For some plugins (e.g. bzr-grep?) this might be a good option though,
>     > indeed.
> 
> Yup, I was thinking about bzr-webdav which is very stable but has been
> broken with 2.5.
While I think we agree that this isn't right for all plugins, it
might be appropriate for some. Including some of these will indeed
help with their testing, but also makes them more easily available to
our users.

I think some candidates (besides perhaps bzr-webdav) are, maybe after
some polishing:

 * bzr-bisect
 * bzr-grep
 * bzr-guess
 * bzr-pager (with a config option, and some polishing)
 * bzr-keywords
 * bzr-email

The reason I picked these is:

 * They don't have any external dependencies
 * They're fairly small, and don't change existing behaviour (except
   for bzr-pager, which I think should have a config option that
   defaults to off)
 * They're already (C) Canonical

Any others?

Cheers,

Jelmer
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <https://lists.ubuntu.com/archives/bazaar/attachments/20120326/a72c6d44/attachment.pgp>