Concrete proposal to moving to bzr

[Matthew East]

Hi all,

The discussion went a bit quiet on the "moving to bzr" thread, but I
think quite a few advantages in bzr were identified in the end, so I'd
like to officially :) propose that we seriously consider the move, and
think about how we might do it.

For me, three issues arise, so that's how I've structured this email.

= How to structure things =

I've talked to Daniel Holbach and Jordan about this, both of whom have
some experience both with working with bzr packages and with our
documentation repository. All of us think the following solution will
work:

A separate bzr branch for each of ubuntu-docs, kubuntu-docs,
edubuntu-docs and xubuntu-docs. This would remove the current awkward
situation that the debian directory for each of the derivatives is in
the wrong directory and needs to be moved to build the package. It
would also allow contributors interested in one flavour just to check
out that flavour. Changes to common documents and directories can be
merged as between different branches whenever they happen.

However, some effort will be required to make this happen. So...

= How to manage permissions =

For that reason I think it's important to keep a single team that has
commit access to these branches: to ensure that we're all working
together, that everyone knows what everyone else is doing, and to
permit people to merge their own changes as between different
branches. I'd propose an ubuntu-core-doc team to handle that. We can
then have an ubuntu-doc team which is an umbrella for groups such as
ubuntu-wiki, ku/xu/edu/u-buntu-docs and so on, which can have less
restrictive entry permissions. I'm not sure if that works, but let's
see if people have better ideas.

= When to move =

Soon? Now that string freeze is upon us, once we get translations
sorted out we should have a bit of time to move on this, and get it
sorted early in the next release cycle.

Thoughts please!

-- 
Matthew East
http://www.mdke.org
gnupg pub 1024D/0E6B06FF