Mooloolaba Notes 2009-11-11 (Day 3)

[John Arbash Meinel]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

These are the notes that I typed up for Wednesday. We talked about a few
ideas. Martin discussed some of the ideas behind Haskell's "Quick
Check", and we thought it would be good to have the idea of a test
'factory' attribute that could be used to clarify "these are the
attributes I'm testing", separate from "this is the setup that needs to
go on to make the test work".

We talked quite a bit about the last few releases. What went right, what
went wrong.

We also talked about the code import system. We have more imports
failing than we would expect, though the vast majority of those never
worked. It is probably not the #1 thing to work on, but makes a very
close #2.

John
=:->


Quick Check

    - Using a test factory for getting the test data
        - Is a method for doing parameterization
        - Allows you to "run everything with Unicode committers"
        - Should be used to make some subset of our testing suite
          better, so that it isn't just 'create a factory method for
          the sake of it'.
        - Should be accessed through self.factory so that it can be
          used for parameterization
        - Has some difficulties with assertions being harder to debug
        - Uses a call with a bunch of keyword args, allows the test to
          be clearer about what it *does* care about versus the rest of
          the state that is arbitrary


Release Retrospectives

    - at major release changes, the minimum version bump is fairly
      painful
    - 'api_minimum_version' is not particularly helpful now that we are
      on 6-month release cycles
    - Users care about the environment, not bzr core
    - Getting better synchronization between plugins and bzr release
    - RM as Release Builder is a bit difficult
    - Early warning of plugin integration problems
    - Release Manager has a mix of "things to do yourself" and "things
      you wait for other people to do", which is a difficult place to
      be
    - Need for bzrtools / missing core functionality
        - branches
        - 'cbranch'
        - colordiff (cdiff)
        - 'shell'
        - 'pager'
        - Interactive commit
    - Merge up "move 2.0.2 => 2.0, 2.0.2 => 2.1.0, 2.1.0 => bzr.dev,
      2.0 => bzr.dev"
    - 'make check' running once helps for releasing
    - faith in 'pqm'. time to get patches in is perceived as more
      difficult
    - Having a stable branch is a big success

    - Should debian be including the beta releases or the stable
      release
        - People running lucid betas, won't default to getting the bzr
          betas unless debian includes the betas
        - upload bzr beta releases to debian unstable
        - if they freeze approx in sync with ubuntu, then they are
          going to be getting the "stable" release

    - Are we including enough bug fixes into 2.0.x
        - should we be landing in dev, giving a couple weeks, and then
          landing into stable
        - Can be difficult to assess

    - What does getting a code into 'updates' imply for overhead for
      the Ubuntu. SRU - Stable Release Updates

    - It is weird that the smallest bit changes for a beta release,
      which potentially has the largest change versus the previous beta
      release.

    - 2.1 doesn't have major features planned that have the same
      "destabilization" that 2.0 had. "Feel like a polish release."

    - How can we trust that 2.1 will be a good release for a Lucid LTS

    - 2.0 release, needs to have the "right combination of sizzle and
      steak".  We had very good performance benefits and content
      improvements, we were missing the "sizzle" of something like
      nested trees. Then we turned around and got bzr-explorer.

      - We are in a better situation now than 6 months ago.
      - Still dealing with network effects, etc. (bzr is good as a
        second to git, and 'better' than hg for many things, and needs
        the discussion to change to that as well.)
      - Is it 'successful'? We should certainly be proud of what we
        did.

    - As a plugin maintainer, can I get help doing new releases by
      advertising where people should grab the 'latest' from.


Code imports

    - Currently average of ~20% failing.
    - Of that, most have never been successful. (~85% of the failures
      never worked)
    - Not a lot of info about the *cause* of the failures.
    - Are we driven by seeing 20% and wanting to fix it, or are we
      driven by users saying "I want this, please help".
    - How many users have it fail and don't ask

    - Why can't you use python 2.5 even if launchpad is running on 2.4.
    - If we are making it a priority then we can probably see
      significant improvement by focussing on it.
    - Imports aren't the 'most important' thing, they are the 'second
      most important thing'.
    - We shouldn't put things at the top of our list, unless we know
      that it is something that our "users" want.
    - The main focus is to "understand what needs to be done", and the
      scope of what that would take.
    - How many people have tried to pull from a failing import?
    - For grumpy, how many people are "blocked" on a failing import?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkr7/ZMACgkQJdeBCYSNAAMNsACfe6X1sHdhQVGbjiRtWtshrgGd
mqEAn2bzvEZRgz4xpeLWw+AP0syh0FUl
=hMBZ
-----END PGP SIGNATURE-----