Dependencies in the PPA for Jaunty

[Martin Pool]

2009/6/23 Vincent Ladeuil <v.ladeuil+lp at free.fr>:
> That wasn't my point.
>
> We already had discussions about the batteries-included approach
> and that should be addressed either by a bazaar package including
> bzr and various plugins OR landing some plugins in core.
>
> None of it has happened yet for lack of time, not for lack of
> understanding or willingness. (aka, it's on the radar but with a
> lower priority than other tasks, yet, I don't know everybody
> TODOs).

Yes, you're quite right.

I think we should draw these lines:

1- bzr-svn, bzr-git, etc - Foreign branch support, which typically has
large external dependencies: probably stays out for now, so that the
source and binary dependencies of bzr itself don't grow.  They're also
being actively developed and value having some independence from the
core, and they have some experience in handling API changes.

2- bzr-gtk, qbzr, bzr-explorer: Ditto.

3- bzr-loom: Useful and moderately popular, but adds a new format with
wide implications.  Supporting this as a stable format would be a big
commitment so I'd say to keep it out and consider these cases post
2.0.

4- bzr-pager, bzr-interactive, bisect, email, grep - many people would
like them, but few will install them while they're in plugins.

5- builddeb, proe - interesting to substantial minority communities,
probably better kept separate.

I'd like to get to the PPA and other packages having a small handful
of packages for the parts that need to be installed separately: the
core, the GUI, foreign branch support.

Here are some specific actions people could take next.

1- Propose merges of code from small plugins into the core.  If it's
code that people are in practice commonly running then I think we
should be gentle on it during review, and we can better look after it
once it's in.  It will depend on a risk assessment of that change:
many plugins just add new commands and aren't likely to break anything
else.  If they modify what's stored we may need to be more careful.

2- Test plugins manually or automatically and file bugs when they break.

3- Improve the packaging scripts to build more of these packages.

-- 
Martin <http://launchpad.net/~mbp/>