launchpad-dev team mailing list archive

[Jonathan Lange <jml@xxxxxxxxxxxxx>]

On Thu, Dec 24, 2009 at 3:59 AM, Maris Fogels
<maris.fogels@xxxxxxxxxxxxx> wrote:
> Jonathan Lange wrote:
>
>> However, I also conducted a bit of a survey on what the pain points of
>> Launchpad development are. There were only five respondents, but even
>> then, there was a strong message: the TDD cycle is too slow, and the
>> cycle of making branches & landing them is too slow. News at 11. Full
>> survey results at http://paste.ubuntu.com/345051/
>>
>
> Jono, thanks for running the survey.  It is great to get some concrete
> information on what people are thinking, even if it's not news  :)
>

My pleasure.

> So our branch-and-fix cycle is too slow.  I was wondering, which steps are
> still present when people work on other projects with faster development
> cycles?  Bazaar? Django? Twisted? Zope?  And when you work on that other
> project, are the steps faster or slower to run?
>

Bazaar is a lot like Launchpad, except without 'make schema', buildout
or dependencies and with a much, much faster test suite. It uses
pre-merge testing with PQM, only one type of code review, and nowadays
has a similar review turnaround.

Twisted does branch-based development, but with Subversion. Their
review process is more cumbersome, slower and more rigorous than
Bazaar's or Launchpad's. They have post-merge testing like us, with
manual monitoring of many, many buildbots. Again, like Bazaar, they
lack 'make schema' et al -- you can just make a branch and go.

Also, bear in mind that our TDD cycle is too slow. Running a fraction
of the tests takes a long time.

>> Also, when I fixed the bug in the AppServer layer, I kept a detailed
>> record of everything I did and how long it took. If someone (perhaps
>> the next build engineer? perhaps you?) were interested, they could
>> make a small value-stream map from the timeline, or write some tools
>> to automate the more repetitive steps.
>>
>> Steps: http://paste.ubuntu.com/345058/
>> Timeline: http://paste.ubuntu.com/345057/
>
> I must often run 'rocketfuel-get', 'link-external-sourcecode', 'make', and
> 'make schema' to create a branch, and that means five to ten more minutes of
> waiting to start work on the actual problem.  (Unfortunately I can not time
> those steps right now: perhaps someone else could?)
>

I don't use rocketfuel-get, since I relish each opportunity to
manually invoke 'bzr'.

> I am not sure that there is enough information in
> http://paste.ubuntu.com/345057/ to draw a value stream map.  Perhaps it
> would help if we knew which steps feel like you are doing something, and
> which steps feel like you are waiting?  Waiting is waste, too.
>

Maybe a VSM is the wrong tool. Anyway, all of the steps that don't
involve me thinking or typing ought to take exactly no time at all,
and all of the steps that involve me typing or clicking should be more
convenient. Specifically:
  * everything from "assigning the bug to me" through to "make the
branch" should be a single conceptual operation that takes zero time.
  * Tests should take zero time
  * Pushing should take zero time
  * "Reproducing the bug" in this case was "setting up the appserver
layer". This should take zero time.
  * Linking the bug to the branch should have happened as part of that
first single conceptual operation I mentioned.

The "steps" paste can probably be used to identify the kind of waste
that comes from too many manual steps, rather than the waste of
waiting.

HTH,
jml