To branch or not to branch

[Jonathan Jesse]

On Tuesday 11 April 2006 07:14, Matthew East wrote:
> On Tue, 2006-04-11 at 16:36 +0530, Bhuvaneswaran wrote:
> > > > > 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.
>
> {snip}
>
> > 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
>
> I'd be against making trunk read-only because that will prevent work on
> dapper+1 from starting whenever people wish to do so. I don't think that
> duplicate work is a problem, because whenever somebody wishes to make an
> exception to string freeze, all they need to do is apply their changes
> to the branch, and then svn copy over to trunk. We'll have to do this at
> any rate under any system, at some stage, so I think it makes sense to
> do so when making the changes.
>
> However, if the maintainers for each document would prefer to merge
> changes later, that's fine by me. Each maintainer can decide what they
> want to do. No problem.
>
> > > * any new hotness for dapper+1 to be done in trunk.
> >
> > Why cant we do it in branch itself ?
>
> Because the package for dapper will be made from that branch, and we
> need it stable. Any dapper+1 stuff needs to be done in trunk.
>
> Matt

I think Dapper+1 should be started right away.  When you merge from trunk to 
branch please only merge those kubuntu docs that where shipped

JOnathan