Subject: Bite size

From: Daniel van Vugt <[email-masked]>
Date: Tue, 28 Jan 2014 14:47:58 +0800

All,

We continue to get a lot of large (~1000 lines) proposals. You might 
notice these are very slow to get reviewed and land. The biggest reason 
(I think) being that no one wants to stop work for a few hours to review 
each revision of each large proposal.

So in the interests of faster reviews, and quicker landing, please try 
to keep merge proposals small. Where possible.

If you have a large proposal and need to break it up, that's simple...

   1. Create a diff: bzr diff --old :parent > ~/bigone.diff
   2. Edit bigone.diff and delete the parts you don't need.
   3. Create a new branch and reapply the changes:  patch -p0 < 
~/bigone.diff
   4. Test and commit.

or

   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
   5. Test and commit

Finally, remember to pre-merge prerequisite branches into your own 
before proposing it. This will avoid bzr complaining about null 
conflicts arising from recreating the prerequisite branch.

- Daniel

---

From: Marco Trevisan <[email-masked]>
Date: Tue, 28 Jan 2014 12:32:46 +0100

>    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 :(

---

From: Christopher James Halse Rogers <[email-masked]>
Date: Wed, 29 Jan 2014 09:35:50 +1100

> 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.

---

From: Kevin DuBois <[email-masked]>
Date: Tue, 28 Jan 2014 15:03:20 -0800

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 <
[email-masked]> wrote:

> Isn't "bzr shelve" the (almost exact¹) dual of what "bzr add --patch"
> would be?
>
> --
> Mir-devel mailing list
> [email-masked]
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/mir-devel
>
>

---

From: Marco Trevisan <[email-masked]>
Date: Wed, 29 Jan 2014 12:07:47 +0100

Il giorno mer, 29/01/2014 alle 09.35 +1100, Christopher James Halse
> of diff. This shouldn't actually be hugely difficult, but I've never got

Well, yes... It's quite similar, but you've to handle things in a
"reversed mode".
I mean, you have to select the hunks that you do NOT want to commit
(where in git add -p you select what you want to), so it works quite
well in practice, but I still miss the ability of splitting hunks or
editing them only before committing (i.e. if you left a debug line in
the middle, you can't just ignore that).

---

From: Marco Trevisan <[email-masked]>
Date: Wed, 29 Jan 2014 12:22:48 +0100

> 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.

Well, that's not completely true. I mean, a part that having ccache can
help even using different folders, but you can setup bzr using the
lightweight checkout mode that allows you to use just one single work
folder for the working branch, while easily switching between branches
that are, only logically, in different folders.

So at the end I've:
unity
├── BRANCHES
│   ├── 5.0
│   ├── 7.1
│   ├── ...
│   └── feature-1-branch
├── workdir
│   ├── build
│   ├── cmake
│   ├── dash
│   └── ...

Where all my work is done only in work dir, and I can use bzr switch to
move to a different branch that I might create or fetch in BRANCHES.

See [1] for more hints, but that definitely made my workflow with bzr
much more productive (so, that switching branch and recompiling only
rebuilds what has changed).
Ah, also with using the bzr q* tools, where especially qdiff is a must.

[1] https://www.taoeffect.com/blog/2009/06/using-bazaar-like-git-repoalias-plugin/

---

From: Michał Sawicz <[email-masked]>
Date: Wed, 29 Jan 2014 13:27:42 +0100

> Ah, also with using the bzr q* tools, where especially qdiff is a must.

I've been using colocated branches for a while now (lp:bzr-colo), that 
let you work within a single checkout and referencing the other branches 
by a colo: prefix. Biggest problem I've encountered is that their 
location is stored absolute, so once you colo-ify your repo, you can't 
move it about without a few hiccups.

-- 
Michał (Saviq) Sawicz <[email-masked]>
Canonical Services Ltd.

---

From: Christopher James Halse Rogers <[email-masked]>
Date: Thu, 30 Jan 2014 09:22:23 +1100

> time if something goes wrong.

I've been trying out bzr-pipeline for work that I know a-priori is going
to require multiple branches; that's worked quite well for me, and is
colocated.