commits to master

[Boudewijn Rempt]

On Friday 06 April 2012 Apr, C. Boemann wrote:
> Hi
> 
> In Berlin last year we agreed that we would move to a 4 month release cycle 
> and in order to do that we promised ourselves we would keep master in a 
> releasable state only merging things when it was ready to be released.
> 
> I don't think we have taken that to heart yet. Master is currently broken 
> (hello Dag), and we commit stuff without review just like we always have (hello 
> myself, and several others).

Guilty as charged...

> I think we should at the very least do the following:
> 
>  - Mandatory publishing in branch if touching cmake files, so others can test 
> it before merging to master.
> 
>  - Fewer commits, on commit per feature, not one per small change.  If we ever 
> want to go back bisecting it's important that the history is in as a complete 
> state as possible. This doesn't mean we shouldn't split into sub commits, but 
> let's try to avoid more than 2 or 3. As an example: changes made as result of 
> reviews should be squashed into the main commits of the feature.
> 
> Now having small commits to go through when debugging a new features is just 
> fine and can happen in a SUB branch. That branch is not supposed to be merged 
> to master until it's totally complete and tested anyway. So when it's ready to 
> go to master, we simply create a single commit out of that branch and commit 
> that to master. If you want the feature branch can stay forever, but we 
> shouldn't pollute the master.


There's two ways of going about this:

* never merge master in your branch and doing git rebase -i to squash history together
* after finishing the branch, merge with master, get a diff to master and commit that diff

I'm still not sure what's the best way -- it might vary from case to case.
 
> Now all this assuming we want to have a short 4 month release cycle. If we 
> want to keep the 6 months or probably a year, then a less strict commit policy 
> might work.

For a four month release cycle, I think we also need to create a release branch as soon as the release process begins and keep master always open for new features.

And we need to figure out what to do with small bug fixes. I'm not not convinced that we will speed up development and keep everyone motivated if we need a review for every bug fix. 
-- 
Boudewijn Rempt
http://www.valdyas.org, http://www.krita.org, http://www.boudewijnrempt.nl