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