Before too much time escapes here is a post on Day Two of Open Source Bridge. As several others have noted, the talks at Open Source Bridge were consistently very good and covered a variety of open source topics.

I enjoyed each of these talks and learned something interesting at each one. Here are some rough notes and key thoughts I took away from each one.

The Linux Kernel Development model–Greg Kroah-Hartman

  • rapid development is an understatement here
  • ~5,000 commits a day!

Effective code sprinting–Reid Beels, Audrey Eschright, and Igal Koshevoy

  • start by inviting a core group of people you know are interested in helping, then invite invite everyone else
  • be very friendly and help direct people that aren’t sure how to get involved
  • engage everyone including people that are not coders
  • on the day of the code sprint work in very short increments– ~45 minutes
  • by the end of the day have something new that works
  • code spints work best with co-located teams
  • it can be done non-co-located teams, but it ususually only works well if the team has worked together in person previously

Project Management Should be Boring!–chromatic x

  • for successful time based releases one development branch should be stable and releasable at any time
  • if quality is low:
    • you can’t freeze harder
    • creating more RCs doesn’t fix the problem
    • the cause is that you are not “done done” (really done)
  • heroics are not sustainable or repeatable
  • take the scheduling factor out of the release and just pick a weekly set day
    • Tuesdays at 9 AM are usually good
  • if the bug count keeps escalating you aren’t closing or reducing bugs effectively
  • all bug trackers are a roach motel over a black hole
  • scope re-factoring process:
    1) leave the code a little cleaner than you found it each time you touch it
    2) set aside time every week to clean up something that is broken–Friday afternoons are good for this
    3) create a regular and well understood deprecation cycle–the Linux kernel does this extremely well
  • software should be getting easier to maintain over time–otherwise you have problems!
  • never adjust estimates
    • negotiate scope, but not quality or estimates
  • asking “why” five times, going deeper and deeper with each response, usually leads you to the root cause

Bazaar vs git smack down–Emma Jane Hogbin & Selena Deckelmann

  • a fun look at the differences between bazaar and git.
  • know what you want to use it for–each of their strengths and weaknesses
  • if you aren’t sure, go with the source control management application that is most used by the people you work with–they can help support you

Re-factor Your Brain: Meditation for Geeks–Christie Koehler

  • we tend to react less to situations and respond more thoughtfully when we are relaxed–meditation helps to relax the body and the mind