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)