nontrivial features/bugfixes

[Vlad Skvortsov]

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.

[Ivan Glushkov]

Post by Vlad Skvortsov
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.
* 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.

[Oleg G. Sharov]

Здравствуйте, Ivan.

Post by Ivan Glushkov

Post by Vlad Skvortsov
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.
* 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.

Me too.

Post by Ivan Glushkov
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").

???

Post by Ivan Glushkov
* 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 the number of reviewers should depend on task difficulty.

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

I propose to create these branches when they need.

[Vlad Skvortsov]

Post by Ivan Glushkov

Post by Vlad Skvortsov
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.
* 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?

Post by Ivan Glushkov
* 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.

Post by Ivan Glushkov
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.