goals for 0.10 development

[Michael Ellerman]

On 8/2/06, Martin Pool <mbp at canonical.com> wrote:
> Robert and I spent some time yesterday talking about the next bzr
> release cycle.  Robert previously posted a release timeline that will
> let us get new features out on a particular date.  But what new
> features?
>
> In general anything can come in that meets our review criteria of user
> experience, code quality, and test coverage.  For any patch, at least
> one of these should get better and none should get worse.  So if there
> is some particular itch you want to scratch, by all means go ahead; and
> if you aren't sure how to test it Robert will likely be happy to help
> work it out.  There are also some existing itches in the bug tracker
> that can be triaged or fixed.
>
> That said, here are some things people might like to work on, and that
> Canonical people will be working on.
>
> Some of these require discussion and/or specs about what should be
> done.
>
> High priority: Considered to be adoption blockers:
>
>  - Tags (mbp to spec, needs decision, spec, about how they're versioned)
>  - Smart server (mbp, andrew, needs to be pushed & explained so other people can
>    contribute)
>  - User documentation
>    - Select some user stories and make sure someone could work out how
>      to do them from the manual
>    - Audit that all non-hidden commands are discussed in the manual
>    - Make a dump (e.g. to html or text) of all online help and review/audit
>    - Upload manual and online help in html form to doc.bazaar-vcs.org
>
>  Medium priority: Important long term work but not severe impact

>   - bzr log per file to show more relevant data, and be faster. (needs
>  speccing from ui aspect, mbp to do so, then ???)

Personally I think this is an adoption blocker. On large trees it's
very useful to be able to say "show the log entries that touch this
file/directory tree". Performance would be nice, but the functionality
is key IMHO.

Equally useful is being able to generate a log that includes the diff,
this makes it easy to search for a certain addition/removal of code
and easily identify which change caused it. Obviously you need to do
something intelligent WRT merges.

There needs to be a way to get the diff between a revisionid and it's
parent* without any extra fuss, ie:
  bzr diff -r revid:michael at ellerman.id.au-20060722073445-c88ec248ad3f4799

* Obviously merges make this harder, but you can just pick one parent
and have a flag to change which one is used.

I realise the best way to get that all supported is to write it myself :)

cheers