launchpad-dev team mailing list archive

[Gary Poster <gary.poster@xxxxxxxxxxxxx>]

Attending: benji, frankban, gmb, gary_poster
Apologies: bac

= Project plan =

We're waiting on IS & fixing bugs.  We all knew this.

= Tricks learned =

benji: re-remembered apt-get build-dep: get all build dependencies. 
Nice for Python packages.  Worked well to get dependencies for 
testrepository development.  Used virtualenv to update dependencies past 
what the system had.

frankban: lxc-ip script (slack time): ctypes is new.  learned that 
buffer overflow erros are still a concern in a ctypes; made a slice 
trick to prevent as a quick hack; is curious to know if there is a 
better approach.  Maybe explicit ctypes constrained buffer?

frankban: gary_poster asked him to mention how he solved the 
UncleanReactorError bug 974585. he made a temporary patch for zope test 
runner that checked after each test to see if some undeleted callbacks 
remained in the Twisted reactor.  This identified the problematic test.

gmb: if you criticize your own project, you will make friends quickly, 
and they will tell you ideas on how to make it better.  This worked 
nicely for ideas on how to improve LP developer documentation, which he 
would like to have for his UDS talk.

= Successes =

Nothing to learn from.

= Pain =

== subunit/testtools/testrepository coordination ==

We experienced a lot of coordination pain, blockage, and stop and go 
when trying to get subunit/testtools/testrepository support for 
identifying the tests that each worker ran for a given test. Jono Lange 
was a huge, gigantic, Superman help, but coordination outside of the 
squad was still slow and rough. We discussed this a bit but eventually 
agreed with benji that the kanban board worked exactly as designed.  We 
pushed everything through to the end, we did some interesting slack time 
studies, and we don’t have WIP blocking us from taking advantage of the 
progress.

== Duplicated work ==

[This topic was from two weeks ago, when we forgot to have our meeting.] 
 We duplicated work with jml on testtools.  In this case, we could have 
done better: we did not file bugs and mark our participation before 
diving in.  Doing these sorts of things--updating coordination artifacts 
to reflect reality--is important.  Coordination still might not happen, 
but there is no chance at all if you don't use the accepted 
communication channels.  Triggers to make us update or file bugs are 
important.  Sometimes we can be working on one task, and find ourselves 
trying to solve a related bug along the way without ever communicating 
the effort.  Can we identify triggers, or mental checkpoints, to make 
sure these coordination opportunities are followed?  We did not discuss.