Mooloolaba Notes 2009-11-11 (Day 3)
John Arbash Meinel
john at arbash-meinel.com
Thu Nov 12 12:20:35 GMT 2009
-----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 ubuntu-distributed-devel
mailing list