nontrivial features/bugfixes

[Vlad Skvortsov]

Ivan Glushkov wrote:
> 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").
>   

What do you mean?

> * 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 think 2 is needed. We are not committed to any deadlines, so we can 
take our time to make sure the code looks good.

> I propose to create name-branches "gli", "oleg", "vss", i.e. not to
> create new branch every time.
>   

I'm not in favor of this. First, a committer may work on several 
non-trivial issues at the same time. Second, it makes merging harder. 
Third, it's not clear what's inside the branch at any given point of time.

-- 
Vlad Skvortsov, vss at 73rus.com, http://vss.73rus.com