Re: python-networkx_1.10-1_amd64.changes ACCEPTED into experimental
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.
In other distributions (Red Hat and Ubuntu), everyone is aware of this
kind of issue before uploading, and this kinds of things don't happen.
There's a set of packages, goals and results for which these
distribution care about, so package updates aren't just uploaded blindly
without first making sure there's no grave consequence. I wish we did
the same. That's a way more important than respecting package ownership
for uploading to Experimental when there's no other reverse dependency
(and within a team ... glups!). I do see that this view isn't shared
among the persons who were self-appointed as "team leaders" though. In
the long term, this lowers a lot the overall quality of Debian, so my
hope is that everyone realizes what's important.
Yes, probably what I did wasn't the correct social way to do it, since
Sandro doesn't like it. But it was technically right to do so. I was
also shocked to read that it was bad for me to "care more about
OpenStack". Yes, of course I do. As this is what my employers pay me
for. Also because I spend countless hours on it, every day. But does it
mean I don't care about anything else in the archive, and don't mind
breakage of other components? Certainly not. And I expect everyone to
have respect for the Debian archive as a whole, do correct transitions
and so on (yes, transitions... also for Python modules...).
Anyway, these was only examples to explain that coordination for package
uploads to Sid is important, the same way I took care of not uploading
networkx to Sid, to make sure I wouldn't break anything. It was *not* to
point finger at the current mock maintainer. Sorry if you took it for
yourself. I didn't even complain to you, the actual maintainer of mock.
If I though it was so bad, I would have. What I think is at fault here,
is upstream, who IMO should have write a deprecation message instead of
just removing the methods (and I already wrote to Robert about it). So
please don't take it personally.
Cheers,
Thomas Goirand (zigo)
Reply to: