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

[Vincent Ladeuil]

>>>>> Wichmann, Mats D <mats.d.wichmann at intel.com> writes:

    > 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.

Yup, this was mentioned as pre-requisites for inclusion when it was
discussed and still holds.

    > 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.

Yup, I'm not proposing to include everything and the core team resources
are indeed limited so we won't be able to maintain each and every plugin
anyway.

The idea is more to find which plugins add enough value to bzr itself
that our time is better spent fixing breakage as soon at it appears than
having to fix it anyway long after which is always more costly.

The issue with trying to maintain compatibility when the core changes is
that we are often too conservative because it's hard to know if a change
will really break some plugin and if maintaining compatibility is harder
than fixing the plugin itself.

       Vincent