commits to master

[C. Boemann]

On Saturday 07 April 2012 10:54:05 Boudewijn Rempt wrote:
> 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.

interactive rebasing and squashing works as long as you have not made your 
commits public yet. Once they ar public git will not let you rewrite history 
like that- now there may be a force option but i havn't found one yet



> 
> > 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.
Yes, although this has a problem of it's own: it require us to commit to two 
branches.

> 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.
No I agree, and if you notice, I didn't say we should. We should still use 
what work on a case by case basis, but we should do it with a renewed sense of 
responsibility of not  messing up development for others. Our cycle are now so 
short it's costly to miss even a few days due to hastily introduced bugs. Not 
all can work on calligra every day and so it may be a week or two before next 
chance arises. Therefore master should always be in a mint and working 
condition.

Another reason is that with confidence in master our release preparation period 
can be reduce with more joy for everybody.