Re: python-networkx_1.10-1_amd64.changes ACCEPTED into experimental
On 6 October 2015 at 01:51, Thomas Goirand <zigo@debian.org> wrote:
> On 10/05/2015 09:37 AM, Michael Fladischer wrote:
>> On 2015-09-30 10:53, Thomas Goirand wrote:
>>> * The maintainer of mock uploaded version 1.3 to Sid, which created RC
>>> bugs (FTBFS) on maybe more than 20 packages currently in Sid, even
>>> though upstream (Robert Collins) is employed by HP and knew OpenStack
>>> Kilo (currently in Sid) would break with his new changes.
>>
>> So much for the finger-pointing. Just to set things straight: Uploading
>> mock-1.3 to unstable was the right thing to do as it uncovered all the
>> broken/misused assertions in the tests that silently passed before but
>> never actually checked anything related to their test-case.
>>
>> I see no use in tests that unconditionally succeed every time they are run.
>
> But this created lots of RC bugs which were not really needed, as the
> affected packages worked otherwise perfectly (I did run Tempest tests to
> functional-validate these packages). Uploading mock to Experimental
> until OpenStack Liberty could be uploaded to Sid was the correct thing
> to do. Never the less, I had (and have) "fixed" many packages that were
> affected (mostly by disabling some tests), but IMO, this didn't improve
> at all their quality.
>
> Site note: at this point, since Liberty will be released in 10 days, I
> wont fix the remaining FTBFS (there's 2 currently in Sid because of mock
> 1.3): I prefer focusing on the next release rather than fixing what's in
> fact already working. Uploading all of Liberty to overwrite Kilo in Sid
> will fix it all anyway.
>
> It is also to be noted that mock is maintained by upstream OpenStack
> people (ie: Robert Collins), and therefore, should be released in Debian
> at the same time as other testing tools and the rest of OpenStack:
> testools, testscenarios, subunit, testrepository, and many more. So in
> the future, I'd advise to follow upstream release schedule. I would
> encourage, if you don't mind, to put mock into the PKG OpenStack team,
> because that's where it belongs. If we don't do that, and without being
> careful, then breakage is to be expected.
Hang on a second here. I, like many others, wear multiple hats.
The things you listed that I help maintain - mock, testtools, etc -
are *not* OpenStack specific. They existed before OpenStack, and
likely will exist after. They have other users, particularly mock
which is very widely used.
Its entirely reasonable to say that known reverse dependencies should
be considered when upgrading packages, but that is in no way OpenStack
specific - and the release schedule of all of the things you listed is
entirely independent of OpenStack.
Its one of the defects of the single-version design of the archive
that we have this uncontrolled use of new releases of software thats
put into it, and - well, thats another discussion. We need to live
with it though.
So I'm +1 on "Check reverse deps aren't significantly broken before
uploading to unstable" as a general principle, not as an OpenStack
specific thing.
-Rob
--
Robert Collins <rbtcollins@hp.com>
Distinguished Technologist
HP Converged Cloud
Reply to: