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 _______________________________________________ calligra-devel mailing list calligra-devel@kde.org https://mail.kde.org/mailman/listinfo/calligra-devel
