Open Stack

On 27 August 2015 at 01:31, Thomas Goirand <zigo at debian.org> wrote:
> On 08/25/2015 11:20 PM, Robert Collins wrote:

>>> So I can't upload PBR 1.3.0 to Sid. This has been dealt with
>>> because I am the maintainer of PBR, but really, it shouldn't have
>>> happen. How come for years, upgrading PBR always worked, and suddenly,
>>> when you start contributing to it, it breaks backward compat? I'm having
>>> a hard time to understand what's the need to break something which
>>> worked perfectly for so long. I'd appreciate more details.
>>
>> More of the ad hominens.
>
> Robert, I'm sorry you take it this way. Sure, I was kind of frustrated
> to see all the added work I have for dealing with issues with the newer
> mock. Though I was writing to you directly as we know each other for a
> long time. I didn't intend this as an attack.

Thank you for explaining your intent. Unfortunately it very much came
across as an attack. As a data point, a number of folk reached out to
me privately expressing support for me after your email: I wasn't the
only person to read it as one. I'm happy to work through why it came
across as one if you wish - privately or publically. I'm equally happy
to just move on - feeling better now that I know it was not intended
as one.

>> As I say above, its not a PBR problem. Its badly expressed defensive
>> dependencies in kilo's runtime requirements. Fix that, and kilo will
>> be happy with newer pbr.
>
> That'd be too much work to patch all of kilo's requirements.txt
> everywhere, I'm afraid I prefer to leave things as they are.

It would be substantial work yes - thats why we haven't undertaken it
in the OpenStack git repos either.

>> 6/ Build something in Debian to deal with  conflicting APIs of Python
>> packages - we can do it with C ABIs (and do, all the time), but
>> there's no infrastructure for doing it with Python. If we had that
>> then Debian Python maintainers could treat this as a graceful
>> transition rather than an awkward big-bang.
>
> Even if we had such a thing (which would be great), we'd still have to
> deal with transitions the way it's done in C, which is hugely painful.

It is, though in principle at least it can be less disruptive. I'm not
sure we (wearing DD hat) have made the right tradeoffs in our approach
there. But thats very close to second guessing the folk driving the
transitions, so I'm going to avoid such guessing until I have the time
and inclination to directly help.

>> One can't actually know that. Because one of the bugs in 1.0.1 is that
>> many assertions appear to work even though they don't exist: tests are
>> ilently broken with mock 1.0.1.
>
> FYI, I'm going for the option of not running the failed tests because of
> what you're explaining just above.

Yes, sounds fine.

>>> Now, the most annoying one is with testtools (ie: #796542). I'd
>>> appreciate having help on that one.
>>
>> Twisted's latest releases moved a private symbol that testtools
>> unfortunately depends on.
>> https://github.com/testing-cabal/testtools/pull/149 - and I just
>> noticed now that Colin has added the test matrix we need, so we can
>> merge this and get a release out this week.
>
> Hum... this is for the latest testtools, right? Could you help me with
> fixing testtools 0.9.39 in Sid, so that Kilo can continue to build
> there? Or is this too much work?

Liberty will require a newer testtools, but the patch to twisted
should be easily backportable - nothing else has changed near it (I
just did an inspection of all the patches over the last year) - so it
should trivially apply. [Except .travis.yml, which is irrelevant to
Debian].

However, I'm not aware of any API breaks in testtools 1.8.0 that would
affect kilo - we run the kilo tests in CI with latest testtools
release; you may need the related dependencies updated as well though
- and I'm not certain we've updated the minimum versions of deps in
the testtools requirements.txt - but as long as the test suite passes
I expect it will be fine.

Cheers,
Rob

-- 
Robert Collins <rbtcollins at hp.com>
Distinguished Technologist
HP Converged Cloud