To branch or not to branch

[Bhuvaneswaran]

> > > About this time last release cycle we branched the repo. Are we going to
> > > do it again? I don't really know much about this, so I'm cc:ing Daniel.

I wish to propose a slightly different approach. We can create a
branch and continue all our fixes in branch alone. We can create a new
incremental tag whenever we have string freeze.  In this context, we
need not bother about creating many tags as svn maintains just one
snapshot in its repo irrespective of number of tags and branches.

Being said this, we can make trunk read-only to disable any more
commits till we start our work for next release. When we start our
work for next release we can merge all fixes in latest tag to trunk.
It has lot of advantages mainly

  * simplicity
  * Avoid duplicate work
  * easy visualisation of the repository

In addition, it takes care of couple of things you listed to do:

> * translations to be added to the branch
> * unwanted icons to be deleted from the branch (the source package for
> ubuntu-docs is WAY too large)

We can do this in branch alone.

> * any string freeze exceptions should be done both in the branch and in
> trunk (to save us merging later)

We can do it in branch. During string freeze we can create a new tag out of it.

> * any new hotness for dapper+1 to be done in trunk.

Why cant we do it in branch itself ? Anyhow, we will merge all changes
(except translations ?) to trunk before we start our work for next
release.

> * edubuntu and xubuntu - these docs are not frozen yet, so I'd suggest
> that work on these carries on in trunk, and comes into the branch when
> the authors are ready.

We can still have them in branch.

> * release-notes - these are basically dapper specific documents, so I'd
> suggest these are worked on directly in the branch.

Yes, i suggest the same.

It is just a thought though. It may not be a perfect solution.
Comments are welcome!
--
Regards,
Bhuvaneswaran
www.symonds.net/~bhuvan/
GPG: 0x7A13E5B0