[RFC] Moving uncommited changes from a tree to another.

[Aaron Bentley]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Martin Pool wrote:
> I've been thinking more about plugins vs core.  I think I'm a bit more
> in favour of things going in to core, for a few reasons:
> 
>  - slightly easier to find them
>  - questions can be answered with "use bzr shove", rather than "use
>    bzrtools shove, which you have to get from xxx and install by yyy"
>  - in the process of coming in we can get more design, ui and code
>    review

The process of getting stuff in can also be an argument against plugins,
because it's much easier for people to get code into a plugin than into
the core.

>  - once it's in it will stay tested and maintained

The testing framework does encompass plugins, but you're that it gets us
single-source maintenance.  It also reduces the likelihood that people
will deprecate the interfaces the code needs.

In London, we were talking about the notion of "core plugins"; plugins
we ship that aren't active by default.  Does this mean you've decided
against that?

I think if we're going to have lots of stuff in the core, we should
really look at segmenting the help, to help people focus on the most
useful commands.

> There can be versioning drift - bzr 0.8.2 plugins won't work perfectly
> with 0.9.

This is true, although for bzrtools, people who use packages are taken
care of; upgrading bzr to 0.9 will upgrade bzrtools too.

> So I'd say plugins are approximately best for
> 
>  - when someone wants to experiment unconstrained (as with bzrtools
>    perhaps)

Yes, I look at bzrtools as a place where I can do UI experiments, but I
do care about code quality there.  For the truly hacky stuff, I have a
'hax' plugin.

>  - when it's really site-specific
>  - when it's integration with something else that many people won't have
>    or want to use (editors etc)
> 
> And then there's a middle ground of standard plugins.

I'm a bit confused.  Do you mean "plugins that implement a standard"?

Aaron
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFE2g8R0F+nu1YWqI0RArelAJ9mkPwOqT551Jbtmp7diyuXcaLhSwCbBoUB
CwzGp23LnV8uxhqOKkYuMAg=
=RkmX
-----END PGP SIGNATURE-----