On Wed, Sep 30, 2015 at 9:53 AM, Thomas Goirand <z...@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
