Shipping plugins

[Vincent Ladeuil]

>>>>> Jelmer Vernooij <jelmer at canonical.com> writes:

<snip/>

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

/me nods

    > Including some of these will indeed help with their testing, but
    > also makes them more easily available to our users.

Yup, that's the idea. The sweet spot is to make sure we get less work
maintaining these plugins than trying to maintain compatibility with all
existing ones (without knowing which and blindly keep maintaining
compatibility for features nobody use or when it's easier to fix the
callers). I'm not saying we should stop our efforts to maintain backward
compatibility either but take advantage of merging these plugins to
enhance our plugin support with things like:

- blacklist plugin versions when there are merged into core or at least
  issue a warning so people get an hint that they should stop using them
  (user plugins take precedence over core ones by design),

- fix our test framework so that re-using tests or installing hooks
  become easier (I think we have a bug for that even for internal
  purposes already),

- your ideas here.

    > 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

I agree with that.

    > 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

When this was first discussed[1], one of the check
points was good testing. Since this is pretty arbitrary, I think we
could use coverage as an objective metric and require that any plugin
should have a 100% coverage for being merged. That may not be perfect
but sounds like a good enough barrier.

Some other points we want to check are:

- documentation,
- existing critical bugs.

    > Any others?

A few others that come to mind (I haven't checked them against the
rationale you give above though):

- bzr-xmloutput,
- bzr-pqm,
- bzr-diffstat,
- bzr-search,
- bzr-bookmarks (this one may just need a rewrite instead as most of its
  features can be implemented with the new config framework),
- bzr-rebase ?

But let's do that one plugin at a time ;)

    Vincent

[1]: I don't have the reference handy nor can I remember if this was on
the mailing list or during a sprint. Anyway, we probably want to
summarize the criteria in some doc/developers document.