KLOC

[Cemil Azizoglu]

That said, expect huge (but trivial) branches due to the upcoming deprecations.

On Fri, Dec 16, 2016 at 9:26 AM, Cemil Azizoglu
<cemil.azizoglu at canonical.com> wrote:
> 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