Release testing and the relationship between 'bzr selftest' and plugins

[Wichmann, Mats D]

On Thu, Mar 15, 2012 at 6:57 AM, Vincent Ladeuil <vila+bzr at canonical.com>wrote:

>
> 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 guess we could say this would mirror the kernel.org policy:  push your
code into core; if not, things will likely break.  If it's in core, things
will
get tested.  This would also imply some quality requirements: to get it
accepted, code will have to be reviewed, tests have to be of high quality,
etc.
My impression is a fair number of plugins are temporary itch-scratchers -
I've certainly run into several that did something, but then weren't really
needed by the author any more and sat around kind of rotting... it would
be nice if a process kind of pushed for the idea to be reviewed - is there
a better way to do this, does it belong in core, etc.

Sounds cool, but I'm not sure it completely applies.  core grows ever
bigger - is that a problem for packages?  Does it stretch the
limited-resource
core team too much in dealing with an ever growing set of bits? etc.
In a sense, the whole idea of a plugin arch is that core doesn't have to
deal with everything, others can contribute to solve specific problems.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/bazaar/attachments/20120315/d9be5706/attachment.html>