commits to master

[Thorsten Zachmann]

On Thursday, April 12, 2012 14:50:03 Cyrille Berger wrote:
> I have started to put together a draft of a commit policy:
> 
> http://community.kde.org/Calligra/Policies/Commits
> 
> For now, it is essentially what I said in my emails.
> 
> For the git bisect part, maybe we could have some guideline on what to
> commit in branch,
> could be useful for beginners as well.

I still see problems with just merging a branch to master and bisecting. Quite 
often what is committed to a branch does not even compile. Also it makes it 
much harder to figure out which feature has broken master when branches are 
merged instead of one single commit is made. It often looks like the commit 
was much earlier as e.g. the branch was merged with master quite often. This 
makes bisecting very hard and therefore it means it is quite hard to figure out 
where regressions have been introduced.

> As for the changelog, we can already make use of the "BUG" keyword. But
> what do you think of
> adding a FEATURE keyword, that would be followed by a description ? For
> instance:
> 
> FEATURE: grammatical spell checking

If we have one commit per feature instead of merge it will also be quite easy 
to see which features have been added to master.

Thorsten