Roadmap for Bazaar...

[John Szakmeister]

On Tue, Sep 21, 2010 at 9:24 PM, Martin Pool <mbp at canonical.com> wrote:
[snip]
> That's a pretty good question.  Beyond what you mentioned on the list,
> for the Bazaar team at Canonical we have two complementary
> motivations: to make bzr a good tool that's both approachable and
> powerful; and in particular to use it for vcs-based development of
> Ubuntu.  The second builds on the first through things like
> bzr-builddeb, bzr builder, soyuz build-from-recipe, and our priorities
> with things like foreign branches.  I want bzr to continue to be
> useful to the full range of community/open-source through to very
> corporate users.

Thanks, that's what I was looking for.

> On the qualitative side I'd like to make it easier and more fun to
> make any change.  Patch pilot has, I think, helped a lot, as have some
> of the testing improvements.  To me this is mostly about people having
> enough time to remove sharp edges when they see them.

Again, not to be a criticism, but it's something that gets in the
way... the architecture is a bit difficult to follow.  I realize there
are a lot of layers for testing, and being able to swap out different
formats, etc.  But I think the complexity makes it more difficult to
dive in and help.  I also think some documentation is missing.  For
instance, what should a format 2a repo look like on disk?  What does a
good graph look like?  What does it really mean to have a ghost?  I
think bzr-svn is pushing the line a little, and doesn't match the
intention, but there is no good way to verify that other by reading
source. :-(

FWIW, a simple document is Good Enough.  I used this documentation in
Subversion to help fix numerous broken repositories (well over 500 by
hand, and thousands more with my tool):
   <http://svn.apache.org/repos/asf/subversion/trunk/subversion/libsvn_fs_fs/structure>

Something like that would be great for Bazaar.  Simple, concise, yet
useful enough to re-implement the backend or examine broken branches.

On the flip-side, the team has been extremely consistent, so now that
I know a few things about how you've organized the code, I can
generally find my way around easily.

> Of the things you name, colocated branches are next on the Canonical
> team's todo list, including making them work properly with bzr-git and
> integrating them with looms.  Some work towards this has been done by
> Jelmer and Parth, then nested trees.

Cool.

> Disabling mainline-changing push by default seems reasonable to me and
> will avoid some confusion.  It will not be a very big code change
> because the policy switch already exists, and we can mentor someone to
> do it.  It mostly needs someone to consider the cases and update the
> documentation to make sure it is explained to users and won't block
> anything important.

The one thing I don't like about the policy is that it's so absolute.
It'd be nice if when you tried to push, you'd get a warning that you
were going to change the mainline and error out.  Then you could use
--force to do it anyways, unless the remote branch had
append_revisions_only set to true.  Something like:

append_revisions_only=warn  # Would warn and error, but can be
overridden with --force.  This would be the default
append_revisions_only=false  # Do whatever you like
append_revisions_only=true   # Never allow the mainline changed

> http hosting is probably one place where people outside of Canonical
> can help a lot, because of course we mostly encounter Launchpad
> hosting.  Someone who really feels the itch is best placed to drive
> it, but we will help.

I'm drumming up a few ideas here, but again, finding it hard to dig
in.  There is no document on what the protocol is on the wire, the
verbs that are available, their intended use, etc.  You have to dig
into the code, which is layered, and makes it hard to grasp.  Not that
it's impossible, obviously people have done it.  It's just hard for me
to jump in for an hour in the morning and grok it.  I have to take a
day off (which I may do).

> Nested trees would come after that. I'd like to see nested trees done
> in a hook-like way that is not intrusive when they're not used or not
> being touched.

I'd love to see that.

> I'll also mention that we are looking to hire a very good software
> engineer (to replace Robert, who is now working on Launchpad), and if
> you're keen to work on any of these issues it would be a good way to
> get lots of time to do it:
> http://webapps.ubuntu.com/employment/canonical_BSE/

Thank you.  Personally, I'd love to (I love working on tools that make
people's lives easier), but I'm running my own company at the moment.
I would like to contribute some solutions back though.  And I'd like
to contribute in other ways to the community by offering training for
Bazaar, services to help set it up or repair broken branches, and I'd
really like to write a book... but I struggle explaining the steps
because how you use it everyday isn't how you would start out.

Thanks for taking the time to respond Martin.  I really appreciate it.

-John