Mooloolaba Notes 2009-11-11 (Day 3)
Gary van der Merwe
garyvdm at gmail.com
Thu Nov 12 13:41:13 GMT 2009
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-----
>
>
More information about the bazaar
mailing list