Diff for "yellow"

Not logged in - Log In / Register
Differences between revisions 32 and 33
⇤ ← Revision 32 as of 2012-05-17 14:31:05 →
Size: 3475
Editor: gary
Comment:
← Revision 33 as of 2012-05-23 12:36:41 → ⇥
Size: 2381
Editor: gary
Comment:
Deletions are marked like this. Additions are marked like this.
Line 40: Line 40:
 * Frankban: MultiArchSpec: 32 bit and 64 bit on same Debian machine: C libraries go into different directories. LXC is starting to do that in quantal. If you use Python and ctypes, path search by default in precise does not include MultiArchSpec. You need to manually look for the MultiArchSpec versions. /usr/lib/`dpkg-architecture -qDEB_HOST_MULTIARCH`/[NAME OF LIBRARY] is location. MORE DETAILS: By default, ctypes looks in the libraries returned by `ldconfig -p`, which has the format of, for example, "libHalf.so.6 (libc6,x86-64) => /usr/lib/libHalf.so.6". This knows about MultiArchSpec (for instance, see `cat /etc/ld.so.conf.d/x86_64-linux-gnu.conf`) but doesn't appear to understand the nested directories that lxc uses. Therefore, you must do it manually.
 * Frankban: sudoers to make lxc-ip: frankban ALL = (ALL) NOPASSWD: /usr/bin/lp-lxc-ip .
 * Frankban: Pay attention if you modify your sudoers file, because if you introduce an error you lose root (and have to start Ubuntu in recovery mode). visudo for the win (it parses before it saves and complains if you do it wrong).
 * Gary: lxc docs are here: https://help.ubuntu.com/12.04/serverguide/lxc.html
 * Brad/Benji: hints for dealing with strace blather in diagnosing non-hanging program?		  * Not buildbot with Juju. Jenkins? Net positive, but in future question directives? Have time associated with answering that question, when we propose? Kind of like agile.

Yellow Squad Wiki Home

https://launchpad.net/~yellow/+mugshots

Slogan for public consumption: Go go Golden Horde!

Slogan when we feel tired: Go go Yellow Banana Slugs!

Current project is LEP/ParallelTesting .

Weekly review call checklist

  • Briefly review where we are in project plan.
  • Any new tricks learned?
    • Collaboration tricks?
    • Debugging tricks?
    • Communication tricks?
    • Checklists? Processes?
  • Any nice successes?
    • Can you attribute your success to anything beyond the innate brilliance of yourself and your coworkers?
  • Any pain experienced?
    • Questions to ask:
      • Are there any cards that are/were taking too long to move?
        • Are they blocked?
        • Are we spinning our wheels?
        • How long is too long?
      • Are we not delivering value incrementally?
      • Are we not collaborating?
      • Did we duplicate any work?
      • Did we have to redo any work?
        • Did we misunderstand the technical requirements, the goal, or a process?
        • Was the ordering of tasks that we chose broken?
    • Can we learn from it?
      • Checklist?
      • Experiment?
      • Another process change?

Notes for next call

  • Not buildbot with Juju. Jenkins? Net positive, but in future question directives? Have time associated with answering that question, when we propose? Kind of like agile.

Notes from weekly review call

Resolutions

  • Next "new to us" project (like charms) when we do not know enough to write tests initially, we want to try this process:
    • Prototype (no tests, as a rule)
    • Squad discussion: lessons learned, design decisions
    • Begin coding, TDD.
  • We will read all ~yellow reviews when in feature development.
  • We are interested in using Go for our next project, if appropriate.
  • Short term goal: charm is ready for review next Tuesday, Feb 14. We would like to provide feedback to the juju team about our experience, and we are willing to take time to do so. Gary is reaching out to hazmat and SpamapS to see how it would be best to do this.

Tabled

  • How will we share smaller design decisions that we learn during the day? The daily call is good but not good enough. IRC? micro-blogging?

yellow (last edited 2012-07-23 12:16:16 by gary)