On Thu, Mar 15, 2012 at 6:57 AM, Vincent Ladeuil
<vila%2Bbzr@...> 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.
