[Swan-dev] a different git branching model for Libreswan

[Paul Wouters]

On Wed, 29 Oct 2014, D. Hugh Redelmeier wrote:

> Current model, as I understand it:
> ==================================
>
> master is where everything goes.
>
> We make releases off the HEAD of master.
>
> When we wish to make a release, we freeze master to some extent, until
> the release can happen.  Only things "important enough" break through the
> freeze.  The freeze can go on for weeks because must-have features (eg.
> bug fixes) seem to drag on.

I would not say that was the model we were planning to use, but it is
clearly what we ended up doing.

> What I don't like:
>
> We seem to be in perpetual freeze, with constant temptation to violate it.
> The longer the freeze has gone on, the more backlog and confusion builds
> up.

We currently have two very strong contracting forces going on. Catch up
on development of features and code freeze for release/stability.

> My first solution: personal branches
> ====================================
>
> Create a personal branch, work there, and merge into master when the
> freeze has been removed AND my branch is in a good state.
>
> Problems;
>
> My private branch works against collaboration.
>
> Other folks on the project don't really understand my view of what my
> branch is.
>
> My branches last too long, diverge too much, and are not shared well.
> They don't get exercised and merging creates a big bang.

Yes, I do not like this at all. I much prefer feature branches. I
understand your "clean ups" are not really a set out feature though, so
it does not fit well into the model of feature branch.

> My suggested solution: release/freeze branches
> ==============================================
>
> We should never freeze master.
>
> When we want a freeze for a release, create a release branch.
>
> Work continues on master.

If you do that, the master branch basically becomes impossible to test
for, because test runs will always show up with differences due to
output changes. The change of code and the change of testcases really
need to be bundled, and that won't happen if master is "free for all".
In fact, this is a bit of what we are currently suffering from when
testing master.

> If something should be in the release (eg. a bug fix), it should be
> created in master but cherry-picked into the release branch.

We will very quickly lose the overview of what in master is or still
needs to go into the release branch.

> Alternative solutions
> =====================
>
> This is not a new problem.  Many projects have created models that
> address it.  We could adopt them.
>
> <http://nvie.com/posts/a-successful-git-branching-model/>
> In this one, master is sacred and seems to only include final
> releases.

This is the model (and in fact the actual web page describing it) that
we were trying to deploy. What I like about it is that most of the
messy commits never sees the public light. Only good patch sets do.
Having set that, we have a number of "abandoned" topic branches that
might actually contain code we need, or incomplete topics that have
become more work to merge into development/master branches than they
are to start from scratch. We don't even have an itemised list of these.

> This would be fine as far as I'm concerned.  I prefer master to be
> where development life is lived in an open-source project.

It would be good that people running "stable" software can git pull
and don't see all the mess, so this model does try to do that and
master becomes a clean tree with solid commits only. Developers can
go dive into the deeper mess by checking out the development tree. It
also forces all commits to be categorised as something.

Related, currently most of our bugfixes don't actually appear on our
own tracker. And we neglect our bugtracker mostly. If we force commits
to have bug numbers it forces a cleaning work method.

To end on a more positive note, the reason we are in this mess is
because we have more people working on different parts of the tree
then ever before. This is a good thing.

Paul