launchpad-dev team mailing list archive

[Gary Poster <gary.poster@xxxxxxxxxxxxx>]

= Preamble =

Is anybody out there?

If you read this email, please give us feedback on how we could make our
communication better.  We've gotten some positive feedback on these
emails, but also some hints that they are falling into the tl;dr trap
for some or most people.

Do you have some ideas on how we can better share what we are doing?
I'm trying headlines this time for each item.  Would a blog instead or
in addition be better?

Thanks.

= Attendance =

bac benji frankban gary_poster

gmb is unavailable today (and Monday)

= Project plan =

 * We are waiting on the two new 24 core machines in the data center.
 * We are fixing big bugs and we have a very bad record for passing runs
lately, but it feels like we're about to return to green runs better
than before.

= New tricks =

 * frankban: ``apt-get install stress``

The stress command is a cool debugging tool that is good for seeing how
testrunner works on a loaded machine. It can stress load average,
memory, cpu, and disk writes.  It is good for seeing how testrunner
works on a loaded machine, and he used it to examine some timeout bugs
in our JavaScript tests.

Be careful with arguments because you can freeze your machine.  You can
mitigate the risk in two ways.  First, you can limit the stress to only
a certain amount of time, like 20 seconds.  Second, you can use a dry run.

This tool can also help identify bugs that are actually testing real
elapsed time, which is not reliable in a test environment.  That leads
to our next topic...

 * frankban: Don't test actual elapsed time.

When writing a test that needs to look at elapsed time, test this
virtually, rather than with real wall-clock time.  You could use a mock
or factor your code to get the test behavior you need without actually
looking at the clock.  Never assume anything will be a certain time--the
amount of time between one line in your file and the next cannot be
relied upon.  Benji: time hates us all.

 * benji: termbeamer beta test is going well

Termbeamer (https://dev.launchpad.net/yellow/Termbeamer) is still going
well.  We had a productive handoff thanks to it this week. No new
features this week.

[Message from editor: try it!]

 * benji: checkmarkable.com is available

Robert gave us access to checkmarkable.com.  Have any of us used it?
gary_poster: I tried it for the checklist for this meeting and found it
wanting for this use case: only for simple checklists, a la CHR tasks.

 * bac: Anyone else trying to use HP cloud?

Brad tried to sign up for HP cloud.  He's waiting on an answer back from
Jorge and then plans to try out our EC2 tasks on the HP cloud.

= Successes =

 * gary_poster: lpsetup LEP discussion led to positive changes

We will have a better API for the slack project after working on the
LEP.  benji: It also may have been useful as a marketing/informational
tool.  Engagement with Robert was a particularly helpful aspect of the
process.  (We then discussed lightweight branches and colocated branches
to make sure everyone knew what they were and how to use them.)

 * gary_poster: try getting unstuck by convening a panel

We had two problematic bugs this week: bug 996729 and bug 1007111.  They
were very similar to bug 1004088 from last week.  In all three cases,
the person or people working on the bug were stuck.  When one particular
person saw the bug (benji, bac, and gmb, respectively) that person had
an insight within the first few minutes that unstuck the problem.  These
were big successes.

We agreed that this chain of success might suggest a process: getting
unstuck by convening a panel. When you are stuck, convene a panel of the
entire squad.  Present the base problem as broadly as possible first, to
try and get different approaches from what you are doing.  If that
fails, show where you are stuck now.  Constrain time to 15 or 30 minutes
max, and if there's more than two or three minutes of silence, stop.

This works nicely with our policy to regard any card that hasn't moved
for a day as a problem to address in our daily call.  We can then
convene the panel on the problem at that time, when we are already together.

Convening a panel does not replace collaboration, but augments it.
Collaboration should still be used before and after the panel.

We'll give this a try for a bit and keep using the tool/process if it
seems useful.  We did not establish an official experiment, though we
really should set an evaluation time.

= Pain =

 * gary_poster: gary blocked the board

gary_poster blocked the board with an in-progress card for days, and
then the resolution was “delete the card! We are not doing it after all!
Ha ha ha. Um.” Squad lead responsibilities blocked him, and other
problems took precedence over that card.  Suggestion: gary must
collaborate when he starts a card.  benji: could have own lane, but
probably not as good a resolution.

 * benji: always ping when the hangout url is ready

On IRC, when we are going to have a hangout, always ping when url is
mentioned.

 * frankban: Late-in-project redesign for lpsetup was painful

It would have been better if lpsetup's LEP had started earlier, so that
we would not have had to do rework.  The project was almost ready to be
released.  We redirected/redesigned the project at the end again.
gary_poster: agree, but it is a lesson we discussed last week: when you
work on something LP maintains, do a LEP early.  We didn't do that this
time, and paid the price.

 * gary_poster: The card for bug 996729 is not moving

This is already discussed sufficiently, we decide.