Bzr plugins *must* die!

[Erik de Castro Lopo]

Jelmer Vernooij wrote:

> This sounds more like a specific packaging bug to me rather than a
> structural problem.

The fact that I have hit problems like this dozens of times over
the last many years is an indication that this is a systemic
problem.

When I first started using Bzr, I would pull the sources from
the bzr.dev repo. I stopped doing this regularly because it
kept breaking my plugins.

I then started only using the bzr installed with apt-get. When I 
needed to use bzr on the same source tree with both Dapper and
Hardy, I had to use the backported ppa repo for Dapper because
the default Dapper version was too old to work with the Hardy
version.

Rob has also suggested I try bzr-loom, but because of the problems
I have had over the years I don't like using a plugin I can't
install as a package. I tend to become dependant on plugins and
I need stability.

Despite what I think is a pretty conservative approach to plugin
usage, I'm still getting bitten.

> Pulling code into bzr.dev has other consequences as well though; it
> becomes harder to contribute to those plugins (review etc for bzr.dev)
> and it becomes harder to change their UI because of backwards
> compatibility requirements.

Well isn't better for the developers to face those problems than
the users? :-)

> For some of the bzrtools commands that have proven themselves, that
> makes sense.

What I was trying to use was "bzr shelve". I'm not even sure what else
I use out of Bzrtools.

> What other plugins would you suggest to be merged into core ?

I use bzr_difftools about a hundred times a day. Fortunately its small
and simple so I can fix an version problems that arise. Obviously, that
would not be true for more complex plugins.

Erik
-- 
-----------------------------------------------------------------
Erik de Castro Lopo
-----------------------------------------------------------------
"When your hammer is C++, everything begins to look like a thumb."
-- Steve Haflich, in comp.lang.c++