launchpad-dev team mailing list archive

[Jonathan Lange <jml@xxxxxxxxxxxxx>]

On Sun, Mar 14, 2010 at 9:45 PM, Michael Hudson
<michael.hudson@xxxxxxxxxxxxx> wrote:
> Jonathan Lange wrote:
>> Hello,
>>
...
>>
>> 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.
>

I think we don't 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)
>

Eek!

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

Thanks to you, Rob & Max for the help. Sadly, I think I'm still blocked.

I think subunit is relatively fast-moving compared to our other
dependencies, and I don't think that .deb packaging is the best way to
deal with that. In general, I don't really understand why one package
should be maintained in buildout and another as an Ubuntu dependency.

Further, I don't actually know how to switch it to use Ubuntu
packages, and am just as unclear on what impact that would have on the
buildslaves & prod environments as I am about changing
update-sourcecode.py.

cheers,
jml