KLOC

[Cemil Azizoglu]

One reason for large MPs is we combine multiple things in one MP. I'm
also guilty of that. This is often noticeable in the MP descriptions
of the form : "Implemented feature A, and cleaned up around that area
while I was at it". Ideally these should be broken up into multiple
MPs for a number of reasons :

- ease of review
- increased chance of spotting problematic code by the reviewers
- reverting would revert only the offending change, not the irrelevant parts

So let's not address multiple goals in one MP.

To go one step further, sometimes even reaching one goal can be broken
up into multiple steps. E.g. one can refactor certain parts of the
code in one MP in order to make addition of a certain feature easier,
which can be done in another MP. So when we're planning our changes,
we should try to break the work into logical steps to get there, and
MP each piece separately stacking them onto each other. Actually, we
do this most of the time, but let's be more proactive about it.

Thanks

On Thu, Dec 15, 2016 at 8:26 PM, Daniel van Vugt
<daniel.van.vugt at canonical.com> wrote:
> All,
>
> Please try to keep merge proposals under a couple thousand lines in size.
> Obviously it's not always possible, but I'm not convinced we're trying our
> best to achieve it.
>
> One thing I've noticed with Mir regressions is that often they come from
> large changes of 1000 lines or more. And when that happens it becomes
> difficult to bisect and resolve the bug. It also makes rolling back such a
> change often impossible because the size creates conflicts if rolled back.
>
> - Daniel
>
> --
> Mir-devel mailing list
> Mir-devel at lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/mir-devel