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.v...@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@lists.ubuntu.com > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/mir-devel -- Mir-devel mailing list Mir-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/mir-devel
