Re: python-networkx_1.10-1_amd64.changes ACCEPTED into experimental
On Wed, Sep 30, 2015 at 9:53 AM, Thomas Goirand <zigo@debian.org> wrote:
> On 09/29/2015 03:48 PM, Barry Warsaw wrote:
>> On Sep 29, 2015, at 12:26 PM, Sandro Tosi wrote:
>>
>>> Once again, the python policy about Maintainer/Uploaders has been ignored
>>>
>>> either policy changes or this has to stop at some point.
>>
>> A few observations.
>>
>> The policy should perhaps be better promoted or more explicitly written. The
>> links you provided are useful, but I wonder whether they are easily
>> overlooked, forgotten, or misinterpreted.
>
> I knew the rule. However, I looked too fast. In this case, I just saw
> "DPMT", and though hum... let's upload, to experimental, it's not a big
> deal, especially that *not other package* depending on it are in
> Experimental, so there was no risk to break anything (yes, I did check
> for this before uploading). Seems I was wrong, and Sandro does make it a
> huge deal.
yes you are wrong, and you keep ignoring both the team policy and the
debian policy as well
(https://www.debian.org/doc/debian-policy/ch-binary.html#s-maintainer)
because that serves your interests better this way
> If you think some of my changes are, let me know (I'm sure you also
look to previous replies.
> noticed some good changes which corrected issues from version 1.9.1-1).
> However, let's try to do discuss in a nice way. Finger-pointing is
> pointless loss of time for everyone.
>
> IMO, Sandro, please just relax. It's not as if I broke everything. It's
> just that the debian/changelog stayed for one full month untouched, with
> a single entry from you "New upstream release" and nothing more. So I
> did the work. No need to start a troll thread for this. This has driven
NO! so you should have asked what's going on
> some contributors away in the past, thinking we don't have team spirit.
> IMO, that's truth, and this kind of thread is hurting again.
>
> On 09/29/2015 03:48 PM, Barry Warsaw wrote:
>> Should we have some automated tools to help out here?
>
> If we had Gerrit with the correct ACLs, it would certainly help.
I would say that an email client works best, as that's the tool you
use to contact other maintainers
> On 09/29/2015 03:48 PM, Barry Warsaw wrote:
>> Something like that would go a long way toward mitigating accidental
>> or careless toe-stepping.
>
> I don't agree with the "careless" here.
>
> What's IMO important is to care not to break any other package in the
> archive, and this is *not* addressed by package ownership. In fact, it's
> rather the opposite way: the package ownership culture in Debian is in
> many ways breaking stability. Let me give some examples.
>
> * P1otr broke multiple times many of my OpenStack key packages by
> uploading newer versions of SQLAlchemy without giving enough time to fix
> issues, even though the SQLAlchemy upstream main author works for RedHat
> specifically on OpenStack support.
>
> * 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 long for "Finger-pointing is pointless loss of time for everyone."
just a few lines above..
> This was careless. And to this, I have no say, because the package
> maintainer decides, and whoever uploads the higher version always wins.
> I could even find more examples if you ask...
>
> However, when I upload python-netowrkx in Experimental, where absolutely
> no package depending on it resides, it's an issue, and then I'm called
> "careless", just because someone "owns" the package and feels like I
> stepped on his toes. That, even considering that I'm reaching the
> bi-annual release of OpenStack, on which I worked days and nights for
> the last 6 months, and I really needed that upload to make sure I have
> the same version of the components that upstream is testing against (ie:
yeah that's it, you care only about pkg-openstack and has no interest
to be a member of this team (as it's proved by the fact you keep
uploading general-purposes python modules under pkg-openstak umbrella)
and popping up here only when you need something for OS, clearly not
caring to follow up if something is not working in one of your
changes.
> last version of python-taskflow, itself needed by Cinder and Glance,
> needed networkx 1.10).
>
> IMO, we have a *very* serious problem here, which isn't even bound to
> the Python team. We should IMO rethink our workflow and rules, and the
> way we think about the Debian archive. Not just thinking about our own
> little square of fenced garden.
well, you decided to use unstable/experimental for your OS work, so
this is what you get. either you adapt your workflow or stop
complaining about a not working integration when sid purpose is
completely another.
--
Sandro Tosi (aka morph, morpheus, matrixhasu)
My website: http://matrixhasu.altervista.org/
Me at Debian: http://wiki.debian.org/SandroTosi
Reply to: