Bazaar focus for 2.1 and 2.2

[James Westby]

Just to fill in some background based on my “Introduction” mail.

On Wed Dec 16 01:45:30 +0000 2009 Martin Pool wrote:
> We talked about:
> 
> * vcs imports - very visible so could be good, but not a pressing problem now

These become very important for daily builds, merging Vcs-*, merging
upstreams etc., as we want to work with as many VCSs as possible for
that.

> * could just focus on looms: getting them in the next default format,
> getting them in the core, making them really nice - question about
> whether they should fit on top of recipes or how they should relate

Looms are proposed as a way to improve the packaging experience,
and also solve some problems with the current way things work
(bzr merge-package).

> * could work on current package import failures - mostly by fixing
> bugs in bzr - james_w will investigate, could file some bugs, maybe
> not a productive main focus (because don't have access to that machine
> and not familiar with that code)

This is where the combination of the bzr importer, bzr-builddeb and
bzr failed to work as designed when mirroring a particular package in
to bzr. I sent an example of some of the issues the other day.

> * could work on udd-related merge features - not so much one overall
> story as getting some bugs

Martin, I don't remember what we discussed about this, could you clarify?

> * nested trees for imports - git submodules and svn externals

There are a bunch of upstreams we can't currently import due to the
lack of this feature, so this ties in with the first point.

> * merging unrelated branches in recipes - may need to bring together
> unmergeable pkg and vcs import branches

This is for daily builds. We have imports of lots of upstreams, and
branches of the packaging, but they are not currently directly mergeable.
Making it possible to sidestep this issue would make it easier to
set up a daily build (we can programatically generate a first stab).

> * rewriting branches - james probably working on this; might want help

We have to do this at each of the phases, and so we need to do it to
include the VCS-* branches.

> james_w could nominate a few bugs for 2.1.

I plan to file bugs I know about soon, even if I don't have a small
reproducer yet.

> So I think overall:
> 
> for 2.1 (about four working weeks before rc1 and going to
> safe-bugfix-only mode):
>  * bugs coming from: merging unrelated branches in recipes, pkg and
> vcs import failure bugs, other udd bugs (including specific merge
> scenarios)
>  * filling those bug queues

I think this is good.

I can fill the queues with package import failure bugs, and encourage
my fellow developers to report anything they hit. Who will fill
them with vcs-import failure bugs. Do we have an analysis of which
issues are causing the most failures? Also, looking at the few that
fail for the top 100 would be good (and perhaps setting up imports
for more of that 100.)

Thanks,

James