Mooloolaba Notes 2009-11-11 (Day 3)

[Alexander Belchenko]

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.

Thanks, very interesting. I wish to read other parts as well.

> 
> 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-----
>>
>>
> 
>