unity-dev team mailing list archive

[Sam Spilsbury <smspillaz@xxxxxxxxx>]

Hey Stephen, thanks for the response.

On Tue, Apr 9, 2013 at 7:23 PM, Stephen M. Webb
<stephen.webb@xxxxxxxxxxxxx> wrote:
> On 04/09/2013 05:14 AM, Sam Spilsbury wrote:
>
>
> To summarise: one change per merge proposal.  Whitespace changes and functional changes are two separate changes.

Yes. Although if a functional change necessarily introduces a
whitespace change, then I don't think this is too much of a problem.

>
> I'd also like to add:  make your changes as small as possible.  If you have a large change to propose, see if you can
> reduce it to several smaller incremental changes with dependent merge proposals for sequencing.  It may not be how you
> develop the changes, but it's almost always possible and there are tools [1] that make this easier.  Smaller is better.

Agreed to the extent that this doesn't impose too large a burden on
those proposing changes. Some changes can be large, but not
particularly complex to understand because there is a single theme.
What I'd recommend is that changes should be broken up by theme, with
an aim to minimize diff sizes, but not necessarily for that purpose.

>
>> Doing changes in this manner means that reviewers can get through both
>> sets faster, because the type of cognitive load is different for each.
>> In addition, it means that substantive changes aren't blocked on
>> formatting changes which other reviewers might have suggestions on.
>
> Better. Stronger. Faster.
>
> Other large community projects I've worked on have a policy of rejecting violating changesets.  Those projects have a
> reputation for quality and longevity.  We can seriously consider adopting such a stance.
>
> [1] http://doc.bazaar.canonical.com/plugins/en/pipeline-plugin.html
>
> --
> Stephen M. Webb  <stephen.webb@xxxxxxxxxxxxx>
>
> --
> Mailing list: https://launchpad.net/~unity-dev
> Post to     : unity-dev@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~unity-dev
> More help   : https://help.launchpad.net/ListHelp



--
Sam Spilsbury