Re: python-networkx_1.10-1_amd64.changes ACCEPTED into experimental
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.
If you think some of my changes are, let me know (I'm sure you also
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
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.
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.
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:
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.
Cheers,
Thomas Goirand (zigo)
Reply to: