launchpad-dev team mailing list archive
-
launchpad-dev team
-
Mailing list archive
-
Message #03051
Re: Blocked on upgrading subunit
On Tue, Mar 23, 2010 at 4:25 PM, Bjorn Tillenius <bjorn@xxxxxxxxxxxxx> wrote:
> On Mon, Mar 15, 2010 at 01:23:33PM +0000, Jonathan Lange wrote:
>> 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.
>
> I think we should care, since this opens up the possibility for people
> to change what is being run on our production systems, without us
> knowing about it. Sure, for this particular branch it should be safe.
> But it's easier to have a policy of "point only to branches owned by
> ~launchpad-pqm", rather than "point only to branches owned by
> ~launchpad-pqm, unless we trust the branch". The latters leaves an
> example that it's ok to point to foreign branches that we don't have any
> control of.
>
For the subunit case, I've decided to go for a package dependency. I'm
now blocked on not being able to create a new image.
jml
References