Mooloolaba Notes 2009-11-11 (Day 3)

[Gary van der Merwe]

Thanks for these notes John. I'm going to copy the bazaar ml, because
I think most of it relates specifically to bazaar.

On Thu, Nov 12, 2009 at 2:20 PM, John Arbash Meinel
<john at arbash-meinel.com> wrote:
> -----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-----
>
>