Dogtail scripts in bzr

[Stephane Graber]

On Tue, 2008-01-15 at 20:46 +0000, Henrik Nilsen Omma wrote:
> We've started hacking together some dogtail test scripts. It's quite a 
> messy process because the scripts are rather fragile and often require 
> work arounds to run at all. Simple scripts can be recorded with the 
> recording tool though and can be tweaked by hand by several people over 
> time. The early scripts are just attached to a wiki page: 
> https://wiki.ubuntu.com/Testing/Automation/Coverage
> 
> For this to scale we obviously need some sort of revision control and we 
> should probably also package known good scripts. I propose we adopt the 
> approach used by bughelper in storing clue files, but that we tighten 
> then write access to the bzr repo, because there is a much greater scope 
> for damage with scripts than clue files.
Sounds good

> In bullet form:
> 
>  * We create a simple package for Ubuntu universe called 
> ubuntu-test-automation, udtp or similar. This will contain the vetted 
> desktop self-testing scripts and an update script. For now this may 
> simply be a 'hello world' script.

About the package name, it should contain "ubuntu" as it'll likely be
Ubuntu specific (with the patching done on the different packages).
Then if its only goal is to contain dogtail scripts, Lars'
ubuntu-desktop-selftest would be the best if it may in a near future
also contains other testing scripts (cli) then ubuntu-test-automation
would be more adapted.

> 
>  * We set up a project in Launchpad with a bzr repo for the contributed 
> scripts, analogous to the bughelper clue files repo. Anyone can read but 
> only a few people who have proven python and system knowledge can write 
> to this repo.
> 
>  * After you install the base test package you can issue a simple 'synch 
> with working repo' command to automatically grab the current working 
> tree with the latest scripts. this is clearly opt-in and we may also add 
> a warning that you should only run these tests on a separate account.
> 
>  * We use the bug tracker to take script contributions from a larger 
> audience. This material will initially be added to the working repo and 
> later to the installable package
> 
> 
> Views? Does this give the right balance of security and a sensible 
> workflow? How do we deal with the situation of two versions of the same 
> script, one in the package and one in bzr; simply use a different naming 
> convention?

I think it's the right way to go.
About the package/bzr issue, another thing I wonder is what happens when
Hardy is released ?
We'll start working on Hardy+1 but the new scripts won't work with Hardy
anymore (because new features will be added to 8.10), so we should have
a way to install only the scripts for the current distro.
That could be done either with a separate bzr branch (or a different dir
in the branch) or using a "launcher" script which would check the
scripts' headers containing the list of target version (the best would
be package version).

> Henrik

Stéphane

PS: This mail isn't GPG signed, I'm reinstalling my laptop and sending
this mail from my test computer.