Concrete proposal to moving to bzr

[Dougie Richardson]

Hi Matt,

> = 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...

This is a real advantage - being able to check out individual project 
branches.

I know I'm new but I also worry that this could introduce fragmentation in 
style,
content and direction of individual teams - especially with respect to 
common documentation.
Which follow neatly to:

Not overly familiar with the current management of the project, but will 
this not need to
include a further degree of management at each group level?

> = 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.

As before, really.

> = 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.

Might as well strike while the iron is hot - unless any really pressing 
concerns arise.


Cheers,

Dougie Richardson
dougie at lynxworks.eu
http://blog.lynxworks.eu/