← Back to team overview

launchpad-dev team mailing list archive

Re: Yellow Squad Weekly Retrospective Minutes: June 22


On Fri, Jun 22, 2012 at 10:12 PM, Gary Poster <gary.poster@xxxxxxxxxxxxx> wrote:
>  * gary_poster: When starting a new project, look at our checklist and jml's
> We're officially starting a new stretch project now with lpsetup.  We
> have our own tiny baby checklist for a project.  It also links to a
> getting-fabulously-better-and-yet-ever-depressingly-larger checklist
> that jml has been working on.
> The only real message in our checklist is "hey, prototypes are cool, and
> competing prototypes especially.  And follow those other rules too,
> whydoncha."  jml's is a lot more comprehensive (and he's looking for
> help with automation, if you are interested!).

I'm not just looking for help with automation, I also want help with
gathering existing practices, adding items I've forgotten, organizing
it to be more useful and less overwhelming, figuring out how to make
it work with projects like LP who have their own policies/shortcuts,
and actually using it in anger to see what needs to change.

I think being able to create new projects easily and thoroughly is
important because of the re-use/release equivalence principle:

>  * gary_poster: When apt-get fails...
> Our juju charm sometimes fails on ec2 with errors like this:
> subprocess.CalledProcessError: Command '['apt-get', 'install', '-y',
> '--force-yes', u'your-package-name']' returned non-zero exit status 100

As an aside, when I was doing my first Juju charm recently,
#ubuntu-devel told me to avoid --force-yes, citing apt-get(8):

  This is a dangerous option that will cause apt to continue
  without prompting if it is doing something potentially harmful.
  It should not be used except in very special situations.
  Using force-yes can potentially destroy your system

> It would be really nice to add this automation to the Python charm
> helpers once they are packaged and usable (waiting on bug 1016588).

I didn't know there was such a thing. It would certainly help me, and
probably help others, if the Golden Horde could wrie up all the things
it learned about Juju and share it with their community.

>  * gmb: Beware: global state hates you: doctest die in a fire part XXXII
> The doctest module mucks with stdout, stderr, and __stdout__ and
> __stderr__ by its very nature.  This can make debugging particularly
> unpleasant when you yourself are doing things with stdout and stderr.
> Our solution was to convert doctests to unittests.  bac: The testtools
> doctest matcher makes converting from doctest to unit test a lot easier.

There's a minor gotcha here: testtools' DocTestMatches doesn't have
any flags by default. Launchpad does.


Follow ups