[ckan-dev] New branching and repository policy

Thu Nov 25 10:59:45 UTC 2010

David Read wrote:
> Rufus,
> 
> Thanks for this, although it's probably worth explaining why you propose this.
> 
> I like the idea of branch-per-feature for these reasons:
> * it is one way to tighten up on badly explained check-ins. This helps
> when preparing a release, understanding exactly what is going in.
> * the default branch has fewer check-ins of more complete features, so
> less likely to break as frequently. Bad check-ins would be easier to
> identify and more easily reverted.
> 
> The disadvantages are:
> * a bit of hassle for developers until they are used to it
> * feature branches wouldn't necessarily be on buildbot
> 
> So I think this would be most useful with CKAN expanding more and
> more, but would ask that we get buildbot to test all open branches in
> the repo.
> 
> The article also mentions branching for specific releases, which I
> like - was that your intention? These would be like our current
> metastable branch. Having this would let us 'trial' releases on test
> servers easily. I don't mind this would be branch per release or have
> a continuous branch as we have now for metastable.
> 
> I don't see much advantage of using bookmarks over named branches. You
> can rename bookmarks, but the permanence and easy distribution of
> branch names seems useful.
> 
> I don't see any advantage in each of us push/pulling to a personal
> bitbucket if we're working on a feature branch by default. It's not as
> easy to autobuild, and the changesets are less visible to the rest of
> the team.
> 

And continuous integration won't happen so well. Fewer checkins of more 
complete features causes more http://c2.com/xp/IntegrationHell.html.

The way forward is crisper analysis, better planning, and cleaner codes.

J.

> David
> 