nontrivial features/bugfixes

[Ivan Glushkov]

On 12/11/07, Vlad Skvortsov <vss at 73rus.com> wrote:
> Greetings!
>
> As you may have noticed, I've fallen behind with the development and now
> trying to catch up reviewing commits as old as r2362. There is quite a
> bit of pretty major changes that require a lot of modifications
> throughout the whole source tree. On one hand, per our guidelines, we
> want to do as fine-grained commits as possible. On the other hand, again
> -- per our own guidelines, we want all related changes to be grouped
> together. This is a clear call to use branches, in my opinion.
>
> So, here is what I'd like to suggest:
>
> * from now onwards all issues with complexity other than minor should be
> fixed on separate branches;
> * all these feature branches should be included into autotest right from
> the start (yes, we can tolerate test failure messages on this list);
> * commits on the branches should be as small as possible;
> * merging back to trunk should be performed with approval (review) or at
> least a nod from two other developers;
> * merging back to trunk can be performed in several large chunks (use
> your judgement);
> * commit message for merged chunks should contain revision range and
> statement listing people having approved the merge ("Merging r3456-3490
> from /branches/XYZ. Approved by: gli, oleg").
>
> I also encourage you guys to review all changes made by others. Comments
> are always welcome.
>
> Please respond to this message with your opinions ASAP so that we can
> enforce the policy.

Hi.

I totally agree. I also wanted to propose this.
Some thoughts.
* Some major issues doesn't need to be fixed in separate branch (or
they should become "minor").
* About merging approval. Do you mean the review should be done by the
both "two other developers", or one approval would be enough? (i
think, 1 approval is enough).
I propose to create name-branches "gli", "oleg", "vss", i.e. not to
create new branch every time.