launchpad-dev team mailing list archive

[Michael Hudson <michael.hudson@xxxxxxxxxxxxx>]

Jonathan Lange wrote:
> Hello,
> 
> Skip the next paragraph if you want to go straight to helping me and
> don't care about context.
> 
> Now that we are using a recent zope.testing, I want to ditch some of
> the ugly hacks that I added to our test script by making them genuine,
> tested features in zope.testing itself. I've started this work, and
> zope.testing 3.9.0 has full support for subunit output.
> 
> I'd like to upgrade zope.testing and take advantage of their better
> subunit support, but that requires upgrading subunit too.
> 
> We currently maintain subunit as a sourcecode dependency. We manage it
> in the branch lp:~launchpad-pqm/subunit/trunk. That branch is a
> KnitPackRepository. subunit trunk is a 2a repository.
> 
> If I naively change sourcedeps.conf like so:
> @@ -12,7 +12,7 @@
> -subunit lp:~launchpad-pqm/subunit/trunk;revno=61
> +subunit lp:~subunit/subunit/trunk;revno=120
> 
> I get incompatible repository errors.
> 
> subunit is not a Python package. It's built with autotools, and thus
> making an egg for it is beyond my ken and maybe inappropriate.
> 
> Which leaves me with a bunch of questions:
> 
> 1. Changing sourcedeps.conf to point to a branch that's not managed by
> our PQM is OK, isn't it? After all, we still have to pass the tests to
> change the revno of the branch, so we aren't losing any safety afaict.

As Max said, we are losing some safety.  Not sure how much or how much
we care.

> 2. If I changed update-sourcecode to just do a full remirror if the
> repository formats are incompatible, would we then encounter problems
> when we rolled out to production?

Not sure.

> 2a. How would I find that out without asking the list?

Reading
https://wiki.canonical.com/InformationInfrastructure/OSA/LaunchpadRollout
might provide some clues (I haven't read all of it, tbh)

> 2b. How many times do we have to write branch mirroring code anyway?

Heh heh.

> 3. Should we instead use buildout?
> 
> 3a. If so, how on earth do I package subunit so that it can be used
> with buildout? Bear in mind this is something I doing in my personal
> time, so if it's not easy or the fun kind of hard, I'm not going to do
> it.

Given the nature of subunit, I think Rob's suggestion of using a deb for
it makes some sense.  Although the lack of hardy packages is obviously a
blocker.

Cheers,
mwh