launchpad-dev team mailing list archive

[Jonathan Lange <jml@xxxxxxxxxxxxx>]

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.

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?

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

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

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.

Thanks for your help and your patience with a long email.
jml