Bite size

[Kevin DuBois]

I think we have 3 issues that drive up diff size:

1) Bzr has branches, but they aren't cheap enough. The simple fact that you
have to compile each branch in its own directory is too big of a cost to
branch as often as I would in git. Furthermore, as illustrated by the
conversation above, if you want to split, you can't cherry pick and rebase
very easily, you end up doing a lot of patchwork, and loosing chunks of
time if something goes wrong.

2) For some features, we have a relatively high testing burden. Namely, if
we're tinkering with code that touches the hardware, we have to test across
a bunch of devices manually. My current 'full test' that we do for hardware
changes is effectively 6 devices, and only going up from there! If you have
to set up 6 devices, you've likely burned 2-3 hours in setup time (much
more if there's a problem, if you have to build the full unity stack, or if
your download speed is slow). This is obviously not required for all
branches, but on the branches that it is necessary, its only natural to try
to save testing time by batching the manual testing work.

3) When we have a smaller review, and something crucial is found wrong with
the first one, then the subsequent patches all need tedious updating and
re-testing. Our team has a lot of very good reviewers, and most the time
something needs changing, causing this cascade to the other branches.

Another point to make is that diff size alone is a misleading metric in
judging the effect of a change. If we add a stub and mock in the course of
writing a branch, that alone drives 'the diff size' up 150-200 lines, even
though this is easy to review. A new test file drives up the diff size a
lot too. Furthermore, renames really drive up the diff size, as there are
many places that need updating.

My main take-away point is that although small branches are more pleasant
to review, there are pretty good time-saving reasons for the proposer to
batch some of the changes.

Cheers,
Kevin


On Tue, Jan 28, 2014 at 2:35 PM, Christopher James Halse Rogers <
raof at ubuntu.com> wrote:

> On Tue, 2014-01-28 at 12:32 +0100, Marco Trevisan wrote:
> > Il giorno mar, 28/01/2014 alle 14.47 +0800, Daniel van Vugt ha scritto:
> > >    1. Create a diff: bzr diff --old :parent > ~/bigone.diff
> > >    2. Create a new branch and reapply the changes:  patch -p0 <
> > > ~/bigone.diff
> > >    3. Identify changes to drop: bzr status or bzr diff
> > >    4. Drop them: bzr revert path/to/files
> >
> > Instead of doing this manually, line per line, I think that bzr
> > (q)shelve can be very useful to stash chunks of sub-file changes in a
> > quicker way... BTW I wish we had something like bzr add --patch :(
>
> Isn't "bzr shelve" the (almost exact¹) dual of what "bzr add --patch"
> would be?
>
> ¹: The thing that I miss from git add -p is the ability to split hunks
> of diff. This shouldn't actually be hugely difficult, but I've never got
> around to fixing it.
>
> --
> Mir-devel mailing list
> Mir-devel at lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/mir-devel
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/mir-devel/attachments/20140128/565c8510/attachment.html>