commits to master

[C. Boemann]

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).

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.

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.