Re: python-networkx_1.10-1_amd64.changes ACCEPTED into experimental
On Monday, October 05, 2015 02:51:26 PM Thomas Goirand 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.
I agree that disabling package test suites doesn't improve their quality.
Were these bad tests? Did you report these issues upstream?
> 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.
I think this exhibits exactly the myopia others have complained about.
python-mock has over 200 reverse build-depends in the archive (python3-mock
has almost a hundred more). It may be used by openstack and maintained by
someone who also works on openstack, but it is, by no means an openstack
thing.
python-mock was first uploaded to the Debian archive in 2009. I believe
openstack was started in 2010. Unless your theory of python-mock involves
time travel, I don't think it's possible to make python-mock appear because of
openstack.
> 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.
I'm glad to hear other distributions are perfect. Maybe some day Debian will
get there too.
For reference, except for people who were in on the founding of DPMT (which I
don't think applies to any of the currently most active admins) no one is
self-appointed. Glad you got your facts straight on this too.
If there is going to be a team, working within the team norms is important.
>From my point of view, you pretty clearly don't understand this. You
knowingly ignored the team norms and clearly have no regrets and would do it
again. From my point of view, you are continuing to convince me that removing
you from the team was the correct action.
I think it would be better for Debian, for the DPMT, and for you if you were a
part of the team, but for that to be possible, you have to work within the
team.
Personally, even if the team was the maintainer of the package, I would never
just upload something without giving a ping to anyone who was active as an
uploader. I think it's just polite, even if it goes beyond what the team
strictly requires (note: I did this exact thing over the weekend for pyside,
got a quick ping back and did a team upload - it's not that hard).
If we can't get the social part of Debian right, the technical part gets very
hard. This is not a side issue.
> 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...).
My impression based on your unwarranted hurry to upload python-networkx and
your rant about python-mock is openstack is all you care about.
> 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.
I would really like it if instead of continuing to point fingers at other
people you would engage constructively.
Scott K
Reply to: