Working on two versions in parallel

[Rick W. Chen]

Hello, I'd like to add my thoughts on this issue, sparked by a recent
discussion on IRC.

Wed, 09 Dec, 2009 at 11:53:34 AM +0100, Nikolaj Hald Nielsen:
> > One of our problems with 2.2.2 currently is that we're in string (and
> > feature) freeze, so many patches, ideas, and Merge Requests are on
> > hold. What if we created a 2.2.3 branch, and started to work on two
> > versions in parallel, before 2.2.2 is actually tagged?
> 
> I don't think this is a good idea for a couple of reasons.
> 
> What would happen is the same that always happens when we have a
> stable branch and a "fun" feature branch. We are all suckers for cool
> new features, so the feature branch is what everyone will end up
> running, meaning that there is less focus on fixing bugs in the stable
> branch and less overall testing of it.
> 
> Furthermore, I really don't think that this would solve any issues
> that are not currently solved by git feature branches. I already have
> a few feature branches for post 2.2.2 stuff. There are a few benefits
> of using a branch for each feature instead of one big playground
> branch. First of all, it allows you to work on an isolated feature for
> as long as it takes to get it ready. You do not have to commit to
> getting it into a specific release target when you start working on it
> (as opposed to your idea where you would still have at most 6 weeks, 2
> weeks while stable branch is in freeze and 4 weeks until the
> playground branch becomes the new stable branch and is frozen, to work
> on a feature). Also, and perhaps most importantly, even when working
> on a branch that focuses on just one feature, you are still regularly
> syncing it with master, meaning that you are still contributing
> testing to master, even when working on your own branch. This would be
> much harder on a shared "playground" branch as it ould quickly start
> to deviate more from master. I know I often find issues this way,
> switch back to master to fix it, push and then update my branch to get
> the fix.
> 
> Just my 2 cents.

I think Mark's proposal was inspired by kernel and git's development
work flow. The main difference for Amarok, if we want to adopt a similar
strategy, is that we don't have a central person(s) who does the
integrations. Having everyone being able to commit to a 'next' branch
would be just the same as had it been 'master' instead. So the problem
is that of policy and coordination, and not how we structure our
branches. Leaving the first two to people who are more experienced, I
encourage the idea of shifting main development off master.

Firstly, using feature branches should be a must for just about
anything, and merged in the end (as opposed to rebasing on top of the
integration branch). Single commits are up to the authors' discretion.

Looking at git's own work flow ('man gitworkflows' or [1]), our master is
almost like their next branch. The place where everything "fun" happens;
and also, "next is intended as a testing branch for topics being tested
for stability for master". That way, master is always clean and only
when the topic is stable it is merged back. And in order to keep 'next'
manageable, it is rebased onto master at each release.

Note that when the topic is merged into next it should already be
feature complete, and was branched off from master because that's where
you want to merge into at the end. Any bugs or incompatibilities found
when testing in the next branch can still be fixed on top of that topic
branch. It is also a place where people can see what's coming up next,
and what others are working on. In case there are conflicts, those can
be resolved before merging into master.

So, shifting our work flow will require some effort in keeping
everything in the right place, because everyone has commit access. But
having a proper structure for development is beneficial for QA, which is
an area that should be improved upon if possible.

  1. http://www.kernel.org/pub/software/scm/git-core/docs/gitworkflows.html

-- 
    Rick