Re: python-networkx_1.10-1_amd64.changes ACCEPTED into experimental
[Brian May, 2015-10-07] > > Probably... Now, I've followed your orders not to use Git, General > > Piotr, so why complaining again?!? > > > > Unfortunately, terms like "General Piotr" start looking like personal > attacks; not going to help your arguments. I take it as a compliment (it's a high rank, after all! ;) (and even if it doesn't look like it: I like Thomas, all our conversations in person were nice, even if I approached him due to yet another svn disaster)... I guess it's this evil SVN that causing all the troubles! ;) PS (so that I do not loose my "evil" tag) no, general Piotr says no git until migration is done, bite me ;P -- evil Piotr
Re: python-networkx_1.10-1_amd64.changes ACCEPTED into experimental
On Thu, 8 Oct 2015 at 00:32 Thomas Goirand wrote: > You've only enforced *your own* policy, backed-up by only a small vocal > minority, taking the rule to the extreme (ie: a few days before the Git > migration, it's still not ok to start new projects using Git, according > to you...). > According to the latest schedule I saw https://lists.debian.org/debian-python/2015/10/msg00030.html - and as far as I am aware it is still current, the migration will happen today and tomorrow (although that probably means a US based timezone, not my UTC+10, so will be delayed from my perspective). If this happens, as scheduled, I don't see any point in complaining. If this isn't happening, maybe your complaint is valid. I'm sorry, I (honestly) don't remember. Or are you mentioning the fact > that I had to move my packages that were under Git to another team? > Probably... Now, I've followed your orders not to use Git, General > Piotr, so why complaining again?!? > Unfortunately, terms like "General Piotr" start looking like personal attacks; not going to help your arguments. For the record there are packages in DPMT that are already maintained in git. Django comes to mind. I think there are others, can't think of the package names off hand. The sooner we can move all packages to the agreed git standards, the better. https://wiki.debian.org/Python/GitPackaging
Re: python-networkx_1.10-1_amd64.changes ACCEPTED into experimental
On 10/06/2015 11:36 PM, Piotr Ożarowski wrote: > my point is that you could argue that your packages are better > maintained than ours (less bug reports, wider Python 3 support, > newest upstream releases, more popcon users, ...) but you choose the > fact that you maintain more of them... and then admit you cannot keep > up You made a point that it was a do-o-cratie earlier, pointing out that Sandro did so much, and that you did as well, so therefore you had to be team leader (with the rights to kick anyone?). Therefore, I thought I had to tell that I do a large chunk of Python packaging work too. On 10/06/2015 11:36 PM, Piotr Ożarowski wrote: >> You forced everyone to keep using SVN even after a vote for Git, and > > you mean I enforced our policy which clearly mentions SVN only? You've only enforced *your own* policy, backed-up by only a small vocal minority, taking the rule to the extreme (ie: a few days before the Git migration, it's still not ok to start new projects using Git, according to you...). > at the very beginning of your membership didn't you use your own > workflows in DPMT packages (which you later moved to OpenStack)? I'm sorry, I (honestly) don't remember. Or are you mentioning the fact that I had to move my packages that were under Git to another team? Probably... Now, I've followed your orders not to use Git, General Piotr, so why complaining again?!? >> workflow I'm using within PKG OpenStack? Let's say that's what you are >> referring to, then: I'm the one working on these, and (up to very >> recently) doing it all alone, so why is this a problem to use the >> workflow I found the most efficient? > > you can use whatever you want, but if you want a team to work on these as > well you need to make it easier to contribute to other team members > (and use what team agreed to use) I generally agree with *guidelines*. But they should stay guidelines only, without restricting too much freedom. Sticking with SVN (and even complaining about the use of git-svn), because of stupid rules enforcement, for sure, didn't help to make it easy to gather more contributors. >> This was for the workflow, it probably also includes tooling. > > yes, especially git-svn was causing pain > >> Would you mind telling what you are referring to? > > I did some work in alembic package, then you decided to move it out from > DPMT to OpenStack (where I don't have access) and revert some of my work > (pybuild stuff) because "you don't understand it" without asking me for > any help. Ah... Did it strike you that you could (and still can) apply to be a member of PKG OpenStack? Did you ever thought that I moved it there because you (and a small minority in this team) was forbidding the use of git within DPMT? As for pybuild, maybe it would help if pybuild was better documented (yes, I am writing this even if I know the /Python/Pybuild wiki page...). As it stands, for me, it is as much of a gray area as CDBS. It is fine with very simple packages, but when it becomes more complicated, I'm a bit lost with it. Probably I should have try harder, and get out of my comfort zone. But why are you complaining about all this just now? I don't remember you ever did before. This leads me to think you do have a problem talking to me, despite the fact you wrote you don't have anything personally against me. Otherwise, you would have simply discuss the mater with me normally, apply to PKG OpenStack, etc. I was in fact surprised to see you never discuss anything about alembic, and I regret I didn't attempt to fix the situation. Last, is not using/liking pybuild a point of argumentation for this thread? I really don't think it should. You can't and should not impose pybuild to everyone doing Python packaging. Nor it should be mandatory to use it within the DPMT.
Re: python-networkx_1.10-1_amd64.changes ACCEPTED into experimental
[Thomas Goirand, 2015-10-06] > On 10/06/2015 06:21 PM, Piotr Ożarowski wrote: > >> I probably have more Python modules in my QA page than all the persons > >> involved in this thread... *combined*! No, it's not a competition, and > > > > it's about quantity and not about quality then? I prefer to have more > > maintainers with few packages only rather than having those with over 50 > > (yes, I think I maintain too many packages) > > There we go again, gratuitous accusation with no facts behind. [...] > >> in fact, I would have loved to share this workload with the team, > >> because I have too many. But now I can't anymore. This is in fact what my point is that you could argue that your packages are better maintained than ours (less bug reports, wider Python 3 support, newest upstream releases, more popcon users, ...) but you choose the fact that you maintain more of them... and then admit you cannot keep up > You forced everyone to keep using SVN even after a vote for Git, and you mean I enforced our policy which clearly mentions SVN only? guilty! you mean I didn't notice a vote? guilty! > after others went away because of this. You even refused to have the > team as "Maintainer:" and a Git repository elsewhere, like in > collab-maint (you even complained about this very recently). you mean the fact that way more active members than you should not look around the internet searching for packages and guess (point me to a single documented one please) workflows? guilty! you mean the fact that when I stopped doing that, our new team members started using yet another workflows (which doesn't make the transition easier)? guilty! > Now, on my side, would you mind reminding everyone when I've forced > anyone to use a particular workflow? Or are you referring to the git at the very beginning of your membership didn't you use your own workflows in DPMT packages (which you later moved to OpenStack)? > workflow I'm using within PKG OpenStack? Let's say that's what you are > referring to, then: I'm the one working on these, and (up to very > recently) doing it all alone, so why is this a problem to use the > workflow I found the most efficient? you can use whatever you want, but if you want a team to work on these as well you need to make it easier to contribute to other team members (and use what team agreed to use) > This was for the workflow, it probably also includes tooling. yes, especially git-svn was causing pain (and I was shocked that you didn't think it was a big deal that you removed my work we talked just hours before you overwrote it for the first time and didn't fix it ever since) > Would you mind telling what you are referring to? I did some work in alembic package, then you decided to move it out from DPMT to OpenStack (where I don't have access) and revert some of my work (pybuild stuff) because "you don't understand it" without asking me for any help. BTW, please remove me from Uploaders, I cannot do that PS I don't plan to read more about how evil I am (I already know that! :P), so if you think Thomas raises valid questions, please quote them for me (if possible, rephrase them) -- Piotr Ożarowski Debian GNU/Linux Developer www.ozarowski.pl www.griffith.cc www.debian.org GPG Fingerprint: 1D2F A898 58DA AF62 1786 2DF7 AEF6 F1A2 A745 7645
Re: python-networkx_1.10-1_amd64.changes ACCEPTED into experimental
On 10/06/2015 06:21 PM, Piotr Ożarowski wrote: >> I probably have more Python modules in my QA page than all the persons >> involved in this thread... *combined*! No, it's not a competition, and > > it's about quantity and not about quality then? I prefer to have more > maintainers with few packages only rather than having those with over 50 > (yes, I think I maintain too many packages) There we go again, gratuitous accusation with no facts behind. I do believe I'm doing a good job at maintaining what I maintain. Bugs are addressed in due time (though I have a backlog right now to address). The numbers talk for themselves: https://qa.debian.org/data/bts/graphs/by-maint/openstack-devel%40lists.alioth.debian.org.png >> in fact, I would have loved to share this workload with the team, >> because I have too many. But now I can't anymore. This is in fact what > > share is fine, force us to use your workflow/tools/goals and timeline is not As would say my mother, better read this than being dead... Never the less, it's still a very surprising read, that pushes me to remind you the facts over these last 2 years. You forced everyone to keep using SVN even after a vote for Git, and after others went away because of this. You even refused to have the team as "Maintainer:" and a Git repository elsewhere, like in collab-maint (you even complained about this very recently). Now, on my side, would you mind reminding everyone when I've forced anyone to use a particular workflow? Or are you referring to the git workflow I'm using within PKG OpenStack? Let's say that's what you are referring to, then: I'm the one working on these, and (up to very recently) doing it all alone, so why is this a problem to use the workflow I found the most efficient? This was for the workflow, it probably also includes tooling. Now, if you don't want to share goals and timelines with others, in order to have the Debian archive as a whole, working well, with transitions correctly done, then I don't know what to say. I thought it was commonly accepted in Debian. >> Are you seriously considering that I try to get closer with Piotr, and >> suffer from even more patronizing? For both our mental health, that's a >> very bad idea. > > sorry to hear that, but it doesn't supprise me to be honest as you don't > want to work with me even in package we both co-maintain Would you mind telling what you are referring to?
Re: python-networkx_1.10-1_amd64.changes ACCEPTED into experimental
[Thomas Goirand, 2015-10-06] > You're still avoiding to answer what are the conditions for me to get > back in the team. he did answer and I did as well (see my first private email to you). One more time: you were removed from the team because you promise to change behaviour and then repeat the same mistakes again (and I'm not talking only about uploads, there were "just" few that really upset other maintainers AFAIK). I talked with you in in private about it during DC13 and DC14, I didn't during DC15 (apparently nobody complained about your help shortly before or nobody notified me). A promise is NOT enough anymore, sorry. I will also not give you any number (as you requested) because it's not about playing nice for X days. > Easy to say, after being called a bad team player, a liar (both > implicitly publicly, and explicitly privately), and questioning the so it's the first time this happened and nobody had any issues with your help before as you suggest? > I probably have more Python modules in my QA page than all the persons > involved in this thread... *combined*! No, it's not a competition, and it's about quantity and not about quality then? I prefer to have more maintainers with few packages only rather than having those with over 50 (yes, I think I maintain too many packages) > in fact, I would have loved to share this workload with the team, > because I have too many. But now I can't anymore. This is in fact what share is fine, force us to use your workflow/tools/goals and timeline is not > > Piotr didn't take the action he took in order to personally attack you. He > > took it as a necessary step to protect the team's working. > > There's many ways to "protect the team's working". One way could have > been to try to cool things down, ask me to revert, which I would have. it didn't work before, why should it work this time? > Instead, he immediately jumped on the idea of kicking me away, not immediately, I wanted to do the same what I did previous times, but after reading your comments I just lost hope. > I wonder if it isn't up to the admins of this team to step back a little > bit. no problem at all, if team is not happy with me, I can step back (I admit that I cannot keep up with all admin tasks anyway) > Are you seriously considering that I try to get closer with Piotr, and > suffer from even more patronizing? For both our mental health, that's a > very bad idea. sorry to hear that, but it doesn't supprise me to be honest as you don't want to work with me even in package we both co-maintain (and I might not be the most polite person on IRC or this mailing list, but I never refused to help someone especially when asked about tools I wrote) -- Piotr Ożarowski Debian GNU/Linux Developer www.ozarowski.pl www.griffith.cc www.debian.org GPG Fingerprint: 1D2F A898 58DA AF62 1786 2DF7 AEF6 F1A2 A745 7645
Re: python-networkx_1.10-1_amd64.changes ACCEPTED into experimental
On 10/06/2015 01:43 PM, Scott Kitterman wrote: > On Tuesday, October 06, 2015 09:24:42 AM Thomas Goirand wrote: >> On 10/06/2015 02:12 AM, Scott Kitterman wrote: >>> As I said up thread, I think a break from the team will be helpful for you >>> to re-engage productively. >> I wrote it to you privately. You can't just tell that it's going to be a >> temporary ban, without giving a timeline. You avoided to answer my >> question. I have no proposal of a way to return either. Just saying that >> I can return later to keep your face and appear as a good person in this >> thread will *not* cut it. >> >> And no, I do not wish to send patches to Piotr. If I had to do this way >> (ie: ask someone to commit for me), I would choose anyone but him. > > My apologies for losing track of what what in what thread. It's a lot of > messages, but I should have kept it straight. > > I think that any return to the team should be based on demonstrated work > that's consistent with the team's way of working. Someone will have to > review > it. You have an offer from one of the team admins to do so. You're still avoiding to answer what are the conditions for me to get back in the team. > Please take a step back from being so emotionally involved in what's going on. Easy to say, after being called a bad team player, a liar (both implicitly publicly, and explicitly privately), and questioning the amount of work I've been doing. I probably have more Python modules in my QA page than all the persons involved in this thread... *combined*! No, it's not a competition, and in fact, I would have loved to share this workload with the team, because I have too many. But now I can't anymore. This is in fact what made me really sad. Hopefully, I'll find ways to still keep-up, and another place to find contributors, and ways to get my contributions to the DPMT packages. > Piotr didn't take the action he took in order to personally attack you. He > took it as a necessary step to protect the team's working. There's many ways to "protect the team's working". One way could have been to try to cool things down, ask me to revert, which I would have. Instead, he immediately jumped on the idea of kicking me away, highlighting the fact that it's been hitching him to do so for some years. All this, without taking the time to discuss the mater with me (I don't call 3 few lines on IRC a discussion). This isn't a good leadership and a friendly behavior. I wonder if it isn't up to the admins of this team to step back a little bit. > I know you don't > agree with it (and I don't expect you to), but he's also said he'll help you > with getting things back to you being in the team. > > Don't reject that offer because you're angry. Are you seriously considering that I try to get closer with Piotr, and suffer from even more patronizing? For both our mental health, that's a very bad idea. I still have no answer to that very simple question of what's the condition (or timing) for me to get back in the team. Please answer it. Thomas
Re: python-networkx_1.10-1_amd64.changes ACCEPTED into experimental
On Tuesday, October 06, 2015 09:24:42 AM Thomas Goirand wrote: > On 10/06/2015 02:12 AM, Scott Kitterman wrote: > > As I said up thread, I think a break from the team will be helpful for you > > to re-engage productively. > I wrote it to you privately. You can't just tell that it's going to be a > temporary ban, without giving a timeline. You avoided to answer my > question. I have no proposal of a way to return either. Just saying that > I can return later to keep your face and appear as a good person in this > thread will *not* cut it. > > And no, I do not wish to send patches to Piotr. If I had to do this way > (ie: ask someone to commit for me), I would choose anyone but him. My apologies for losing track of what what in what thread. It's a lot of messages, but I should have kept it straight. I think that any return to the team should be based on demonstrated work that's consistent with the team's way of working. Someone will have to review it. You have an offer from one of the team admins to do so. Please take a step back from being so emotionally involved in what's going on. Piotr didn't take the action he took in order to personally attack you. He took it as a necessary step to protect the team's working. I know you don't agree with it (and I don't expect you to), but he's also said he'll help you with getting things back to you being in the team. Don't reject that offer because you're angry. Scott K
Re: python-networkx_1.10-1_amd64.changes ACCEPTED into experimental
(I was asked not to reply anymore, and I was doing it quite happily, but since it involves a private conversation between Thomas and me, I need to step in) >> I think that generally when one transgresses on someone else's package in a >> way the maintainer doesn't like it's the responsibility of the transgressor >> to offer to fix it. > > I was told not to commit anymore. you need to get your facts straight though: you committed, you uploaded, I complained, you committed what you think were the things to fix, you wrote to me asking if that's what I meant, I requested not to commit anymore as what you did was very short of what's there still to fix. /me really hopes this thread has stopped days ago :( -- Sandro Tosi (aka morph, morpheus, matrixhasu) My website: http://matrixhasu.altervista.org/ Me at Debian: http://wiki.debian.org/SandroTosi
Re: python-networkx_1.10-1_amd64.changes ACCEPTED into experimental
On 10/06/2015 03:31 AM, Scott Kitterman wrote: > > > On October 5, 2015 8:42:40 PM EDT, Brian May > wrote: >> On Tue, 6 Oct 2015 at 09:33 Scott Kitterman >> wrote: >> >>> Except in this case you not only didn't but then got defensive when >> called >>> on it. If you'd just reacted with something like "Oops, made a >> mistake, >>> I'll >>> revert it from svn and ask for it to be removed from experimental." >>> (fortunately for experimental we can do that) then this wouldn't have >> been >>> a big deal. >>> >> >> I get the impression that the complaint was "process wasn't followed" >> as >> opposed to "I didn't want that package in experimental". So unless I am >> mistaken, there doesn't seem to be any need to remove the package from >> experimental. In this particular case. > > I think that generally when one transgresses on someone else's package in a > way the maintainer doesn't like it's the responsibility of the transgressor > to offer to fix it. I was told not to commit anymore. Thomas
Re: python-networkx_1.10-1_amd64.changes ACCEPTED into experimental
Thomas Goirand writes: > You can't write this: > > On 10/06/2015 12:33 AM, Scott Kitterman wrote: > > causes me to doubt the sincerity of this. > > and this: > > On 10/06/2015 02:12 AM, Scott Kitterman wrote: > > I don't think you're intentionally malicious. > > a few hours apart, and get away with it. Take your pick... Those statements are compatible, and Scott has explained them: he's saying you're acting not on malice, but he doubts you're acting sincerely either. > am I an evil liar or not? Please, take a break from this thread until you can discuss the matter more dispassionately. You have told us the stress is making you physically ill; I believe you, and I don't want you ill. -- \ “Are you pondering what I'm pondering?” “Well, I think so, | `\Brain, but if Jimmy cracks corn, and no one cares, why does he | _o__) keep doing it?” —_Pinky and The Brain_ | Ben Finney
Re: python-networkx_1.10-1_amd64.changes ACCEPTED into experimental
You can't write this: On 10/06/2015 12:33 AM, Scott Kitterman wrote: > causes me to doubt the sincerity of this. and this: On 10/06/2015 02:12 AM, Scott Kitterman wrote: > I don't think you're intentionally malicious. a few hours apart, and get away with it. Take your pick... am I an evil liar or not? Thomas
Re: python-networkx_1.10-1_amd64.changes ACCEPTED into experimental
On 10/05/2015 11:17 PM, Barry Warsaw wrote: > On Oct 06, 2015, at 07:00 AM, Robert Collins wrote: > >> The things you listed that I help maintain - mock, testtools, etc - >> are *not* OpenStack specific. They existed before OpenStack, and >> likely will exist after. They have other users, particularly mock >> which is very widely used. > > I intensely dislike the separation between OS and DPMT, for exactly this > reason. Too many packages of general use to Python developers is out of reach > of DPMT. I thought it was mostly a vcs-induced separation It was indeed. > but now I think > it's clear that even after DPMT moves to git, this separation will continue. Unfortunately, yes. Of course, I do want to keep my write accesses for these packages, so even if it was my intention to put them all under the DPMT, I don't see how it can happen now. I wouldn't even be able to write the packages in /git/python-modules if I wanted to... Thought everyone is welcome in the PKG OpenStack team, and it is accepted for anyone to commit, or even upload, as long as it doesn't break everything at once (and even if you do, it's ok, we'll just figure out together how to revert...). >> So I'm +1 on "Check reverse deps aren't significantly broken before >> uploading to unstable" as a general principle, not as an OpenStack >> specific thing. > > +1 also Sure. That's not at all OpenStack specific. > but it's always going to be a spot check for sanity so things will > fall through the cracks. Until we get something like the promotion tests, we > just have to commit ourselves to being diligent within reason before > uploading, and responsible to help fix breakages after they're discovered. Is the proposal to have a CI that would rebuild packages for us against a proposed update, so it can be tested before an upload? Cheers, Thomas Goirand (zigo)
Re: python-networkx_1.10-1_amd64.changes ACCEPTED into experimental
On 10/06/2015 02:12 AM, Scott Kitterman wrote: > As I said up thread, I think a break from the team will be helpful for you to > re-engage productively. I wrote it to you privately. You can't just tell that it's going to be a temporary ban, without giving a timeline. You avoided to answer my question. I have no proposal of a way to return either. Just saying that I can return later to keep your face and appear as a good person in this thread will *not* cut it. And no, I do not wish to send patches to Piotr. If I had to do this way (ie: ask someone to commit for me), I would choose anyone but him. Thomas Goirand (zigo)
Re: python-networkx_1.10-1_amd64.changes ACCEPTED into experimental
On October 5, 2015 8:42:40 PM EDT, Brian May wrote: >On Tue, 6 Oct 2015 at 09:33 Scott Kitterman >wrote: > >> Except in this case you not only didn't but then got defensive when >called >> on it. If you'd just reacted with something like "Oops, made a >mistake, >> I'll >> revert it from svn and ask for it to be removed from experimental." >> (fortunately for experimental we can do that) then this wouldn't have >been >> a big deal. >> > >I get the impression that the complaint was "process wasn't followed" >as >opposed to "I didn't want that package in experimental". So unless I am >mistaken, there doesn't seem to be any need to remove the package from >experimental. In this particular case. I think that generally when one transgresses on someone else's package in a way the maintainer doesn't like it's the responsibility of the transgressor to offer to fix it. It may well be that the maintainer would have declined the offer, but I think offering to return the situation to the status quo ante is appropriate. Scott K
Re: python-networkx_1.10-1_amd64.changes ACCEPTED into experimental
On 2015-10-05 23:45:57 +0200 (+0200), Thomas Goirand wrote: [...] > Upstream will *not* fix the issue, because you know, they "fixed" it in > their CI by adding an upper version bound in the pip requirements, which > is fine for them in the gate. It is fixed in OpenStack Liberty though, > which I will soon upload to Sid. [...] It's a bit of a mischaracterization to say that "upstream will not fix the issue." In fact as you indicate it was fixed within a couple days in the master branches of affected projects. The mock pin in stable/kilo branches is a temporary measure and can be removed if all the broken tests are either removed or corrected (the assumption being that distro package maintainers who have an interest in that branch may volunteer to backport those patches from master if this is important to them). -- Jeremy Stanley
Re: python-networkx_1.10-1_amd64.changes ACCEPTED into experimental
On Tue, 6 Oct 2015 at 09:33 Scott Kitterman wrote: > Except in this case you not only didn't but then got defensive when called > on it. If you'd just reacted with something like "Oops, made a mistake, > I'll > revert it from svn and ask for it to be removed from experimental." > (fortunately for experimental we can do that) then this wouldn't have been > a big deal. > I get the impression that the complaint was "process wasn't followed" as opposed to "I didn't want that package in experimental". So unless I am mistaken, there doesn't seem to be any need to remove the package from experimental. In this particular case.
Re: python-networkx_1.10-1_amd64.changes ACCEPTED into experimental
On October 5, 2015 7:02:58 PM EDT, Thomas Goirand wrote: >On 10/06/2015 12:33 AM, Scott Kitterman wrote: >> Technically right, but socially wrong is wrong. > >I got that point, yes. > >> Reading that and what you >> wrote above, does that help you understand why I question both your >focus and >> the sincerity of your expressions of regret. > >The words that I'm reading from you here are humiliating: it implies >that I would be ready to write anything, including not being sincere in >my apologies, just to beg for still being a team member. > >This last Sunday, I got upset about all of this all day even if I >didn't >want to think about it, to the point my belly was hurting, and I >couldn't spend a good time with my kids. > >Now, reading this, I want to puke... I don't think you're intentionally malicious. I think you're just too wrapped up in it to see it clearly. As I said up thread, I think a break from the team will be helpful for you to re-engage productively. Scott K
Re: python-networkx_1.10-1_amd64.changes ACCEPTED into experimental
On 10/06/2015 12:33 AM, Scott Kitterman wrote: > Technically right, but socially wrong is wrong. I got that point, yes. > Reading that and what you > wrote above, does that help you understand why I question both your focus and > the sincerity of your expressions of regret. The words that I'm reading from you here are humiliating: it implies that I would be ready to write anything, including not being sincere in my apologies, just to beg for still being a team member. This last Sunday, I got upset about all of this all day even if I didn't want to think about it, to the point my belly was hurting, and I couldn't spend a good time with my kids. Now, reading this, I want to puke... Thomas Goirand (zigo)
Re: python-networkx_1.10-1_amd64.changes ACCEPTED into experimental
On Monday, October 05, 2015 11:45:57 PM Thomas Goirand wrote: > On 10/05/2015 04:57 PM, Scott Kitterman wrote: ... > >> 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. > > I'm surprised here by reading these numbers. How exactly do you show a > package's reverse build dependency? "apt-rdepends -b -r" doesn't work... > I remember I did it for mock though ... :( The simplest way to do it that I know of is to use the reverse-depends script in ubuntu-dev-tools (in Debian it works correctly for Debian) and do reverse- depends -b [package]. > > 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. > > That's not the case. It just happens that Robert Collins Robert's already explained this in detail. I'm not sure what you were about to argue here, but the fact that you don't seem to be able to see Robert as anything other than an OpenStack developer is something I find confirms my thoughts about where your focus is. > >> 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. > > That's of course not what I wanted to say. Then say what you want to say. "... this kinds of things don't happen." is pretty unequivocal. > > You knowingly ignored the team norms and clearly have no regrets and would > > do it again. > > WHAT ? I mean ... WHAAAT ?!? > > Do I express myself so badly, that it leads to this? Never, ever, I > wrote something like this. So let me state it once and for all. > > 1/ I have already expressed regrets for this upload. > > 2/ This upload is a *mistake* because I checked too fast packages.d.o > and saw "oh, DPMT, let's upload..." when I should have been more careful > and really check for the actual fields (which were matching the "do not > upload before ping" rule which I knew about, and not the "this is team > maintained, go ahead..." as I thought it was by looking too fast). > > This is what made me say that writing this in a policy wont change > anything: mistakes can still happen, no mater how big you write the > rule. If we wrote "DPMT-do-not-upload" as maintainer, it'd be less prone > to mistakes, as it'd appear as so in the pacakges.d.o page and > everywhere else. The "trick" with uploads / maintainers field is just > too confusing and error prone. > > 3/ No, I wouldn't do it again... > > Is it clear enough now? Re-read my past post, hopefully, you will > realize that this what I wrote in the first place. I hear what you are saying, but the fact that you continued this thread about a mistake you made with unrelated attacks on other developers causes me to doubt the sincerity of this. > > 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 > > Which I did many times too. Except in this case you not only didn't but then got defensive when called on it. If you'd just reacted with something like "Oops, made a mistake, I'll revert it from svn and ask for it to be removed from experimental." (fortunately for experimental we can do that) then this wouldn'
Re: python-networkx_1.10-1_amd64.changes ACCEPTED into experimental
On 10/05/2015 04:57 PM, Scott Kitterman wrote: > I agree that disabling package test suites doesn't improve their quality. That's not what I did, I blacklisted these unit tests which were failing, and kept all the others. As these unit tests were anyway broken, it doesn't mater much. > Were these bad tests? Did you report these issues upstream? Upstream will *not* fix the issue, because you know, they "fixed" it in their CI by adding an upper version bound in the pip requirements, which is fine for them in the gate. It is fixed in OpenStack Liberty though, which I will soon upload to Sid. >> 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. I'm surprised here by reading these numbers. How exactly do you show a package's reverse build dependency? "apt-rdepends -b -r" doesn't work... I remember I did it for mock though ... :( > 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. That's not the case. It just happens that Robert Collins >> 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. That's of course not what I wanted to say. > You knowingly ignored the team norms and clearly have no regrets and would do > it > again. WHAT ? I mean ... WHAAAT ?!? Do I express myself so badly, that it leads to this? Never, ever, I wrote something like this. So let me state it once and for all. 1/ I have already expressed regrets for this upload. 2/ This upload is a *mistake* because I checked too fast packages.d.o and saw "oh, DPMT, let's upload..." when I should have been more careful and really check for the actual fields (which were matching the "do not upload before ping" rule which I knew about, and not the "this is team maintained, go ahead..." as I thought it was by looking too fast). This is what made me say that writing this in a policy wont change anything: mistakes can still happen, no mater how big you write the rule. If we wrote "DPMT-do-not-upload" as maintainer, it'd be less prone to mistakes, as it'd appear as so in the pacakges.d.o page and everywhere else. The "trick" with uploads / maintainers field is just too confusing and error prone. 3/ No, I wouldn't do it again... Is it clear enough now? Re-read my past post, hopefully, you will realize that this what I wrote in the first place. > 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 Which I did many times too. >> 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 b
Re: python-networkx_1.10-1_amd64.changes ACCEPTED into experimental
On Mon, Oct 05, 2015 at 05:26:38PM -0400, Barry Warsaw wrote:
> On Oct 05, 2015, at 09:16 PM, Mattia Rizzolo wrote:
>
> >Isn't this the whole point of unstable→testing?
>
> I guess, although it seems a lot of people run unstable so breakages affect
> more people. I run unstable on most of my Debian machines. I think almost
> nobody actually runs -proposed.
Scott replied with more detailed info about the britney2-derived thing
Ubuntu runs.
And really, as he said and you guessed, ${ubuntu-devel}-proposed is not
meant for humans.
Debian's unstable is run by humans → more people affected by breakages →
quicker fixes. This is how I see it, at least.
And by humans here I mean Debian developers/contributors.
Still getting Debian's britney2 use dep8 tests as a data point for
migrations would be really, really cool+useful.
--
regards,
Mattia Rizzolo
GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`.
more about me: http://mapreri.org : :' :
Launchpad user: https://launchpad.net/~mapreri `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia `-
signature.asc
Description: PGP signature
Re: python-networkx_1.10-1_amd64.changes ACCEPTED into experimental
On Oct 05, 2015, at 09:16 PM, Mattia Rizzolo wrote: >Isn't this the whole point of unstable→testing? I guess, although it seems a lot of people run unstable so breakages affect more people. I run unstable on most of my Debian machines. I think almost nobody actually runs -proposed. Cheers, -Barry pgp2C7LN9TZaT.pgp Description: OpenPGP digital signature
Re: python-networkx_1.10-1_amd64.changes ACCEPTED into experimental
On Monday, October 05, 2015 05:11:26 PM Barry Warsaw wrote: > On Oct 05, 2015, at 02:51 PM, Thomas Goirand wrote: > >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. > > Ubuntu at least does have a technical solution that helps ameliorate > archive-wide breakages, and that is -proposed migration. When you upload > e.g. to wily, it gets diverted to wily-proposed and to get promoted it has > to pass a number of tests. The package and their reverses have to build. > DEP-8 tests have to pass, etc. You can get a nice report about which > -proposed promotions are failing: > > http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuse > s.html > > The downside is that you should probably be proactively checking this list > (poll vs ping) and it can sometimes be difficult to figure out why a > promotion fails or how to fix it. > > But this does mean that the archive itself is very rarely broken, and it can > be a convenient way to stage package updates that may have effects in parts > of the archive you might not be aware of. This is a modified version of britney2, the same tool that Debian uses to manage the Unstable -> Testing migration. I believe the Debian release team intends to add autopkgtests as a blocker for migration and to enable faster migration for packages that pass testing. One difference you won't get around though is that in Ubuntu devel -proposed is not considered suitable for use by humans. It's only there to support running the tests and doing transitions. In Debian, developers are encouraged to use Unstable since that's how we find out stuff shouldn't be in Testing. Another, is that there's no equivalent in Ubuntu of an RC bug blocking migration. Scott K
Re: python-networkx_1.10-1_amd64.changes ACCEPTED into experimental
On Oct 05, 2015, at 10:57 AM, Scott Kitterman wrote: >I agree that disabling package test suites doesn't improve their quality. >Were these bad tests? Did you report these issues upstream? Silently passing broken tests was one of a common pattern of issues I found when making Python 3.5 supported in Ubuntu. The tests were broken, and I reported upstream or fixed the ones I found. I was skeptical about this mock change, and it did cause churn, but it was important for longer term increasing the quality of the archive. >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. Fully agreed, and I think it's a *good* thing we've been having this discussion. It makes me want to double check the assertions about maintainership in the packages I touch, and it makes me be doubly conscience of other maintainer's preferences here. But let's be sure to capture these norms in Debian Python policy or the team wiki pages. I think Scott, you were going to propose some changes to policy in this area? Cheers, -Barry
Re: python-networkx_1.10-1_amd64.changes ACCEPTED into experimental
On Oct 06, 2015, at 07:00 AM, Robert Collins wrote: >The things you listed that I help maintain - mock, testtools, etc - >are *not* OpenStack specific. They existed before OpenStack, and >likely will exist after. They have other users, particularly mock >which is very widely used. I intensely dislike the separation between OS and DPMT, for exactly this reason. Too many packages of general use to Python developers is out of reach of DPMT. I thought it was mostly a vcs-induced separation, but now I think it's clear that even after DPMT moves to git, this separation will continue. The multi-version design of the archive does cause problems. I outlined a big thing that I think Ubuntu has that helps reduce the impact of this. I'm not sure if the same kind of this would help Debian, whether it would be feasible, or even acceptable by the majority of Debian developers. I really think we need to be finding ways to *reduce* the separation between OS and DPMT. One of the things I hope will happen after git migration is subsuming as much as possible from zope-pkg into DPMT since again, there are a lot of general interest packages in that namespace. >Its entirely reasonable to say that known reverse dependencies should >be considered when upgrading packages, but that is in no way OpenStack >specific - and the release schedule of all of the things you listed is >entirely independent of OpenStack. > >Its one of the defects of the single-version design of the archive >that we have this uncontrolled use of new releases of software thats >put into it, and - well, thats another discussion. We need to live >with it though. Right, and observe that it's not feasible to track down *all* reverse dependencies when updating a single package. That's part of why -proposed migration is so nice, an automated system does that tracking for you. >So I'm +1 on "Check reverse deps aren't significantly broken before >uploading to unstable" as a general principle, not as an OpenStack >specific thing. +1 also, but it's always going to be a spot check for sanity so things will fall through the cracks. Until we get something like the promotion tests, we just have to commit ourselves to being diligent within reason before uploading, and responsible to help fix breakages after they're discovered. Cheers, -Barry
Re: python-networkx_1.10-1_amd64.changes ACCEPTED into experimental
On Mon, Oct 05, 2015 at 05:11:26PM -0400, Barry Warsaw wrote: > On Oct 05, 2015, at 02:51 PM, Thomas Goirand wrote: > > >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. > > Ubuntu at least does have a technical solution that helps ameliorate > archive-wide breakages, and that is -proposed migration. When you upload > e.g. to wily, it gets diverted to wily-proposed and to get promoted it has to > pass a number of tests. The package and their reverses have to build. DEP-8 > tests have to pass, etc. You can get a nice report about which -proposed > promotions are failing: > > http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html > > The downside is that you should probably be proactively checking this list > (poll vs ping) and it can sometimes be difficult to figure out why a promotion > fails or how to fix it. > > But this does mean that the archive itself is very rarely broken, and it can > be a convenient way to stage package updates that may have effects in parts of > the archive you might not be aware of. Isn't this the whole point of unstable→testing? Ok, the debian testing migration might do really few checks compared to ubuntu's, but still it's the same thing, and I believe RT would like to add more checks (at lest dep-8 tests) someday. -- regards, Mattia Rizzolo GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`. more about me: http://mapreri.org : :' : Launchpad user: https://launchpad.net/~mapreri `. `'` Debian QA page: https://qa.debian.org/developer.php?login=mattia `- signature.asc Description: PGP signature
Re: python-networkx_1.10-1_amd64.changes ACCEPTED into experimental
On Oct 05, 2015, at 02:51 PM, Thomas Goirand wrote: >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. Ubuntu at least does have a technical solution that helps ameliorate archive-wide breakages, and that is -proposed migration. When you upload e.g. to wily, it gets diverted to wily-proposed and to get promoted it has to pass a number of tests. The package and their reverses have to build. DEP-8 tests have to pass, etc. You can get a nice report about which -proposed promotions are failing: http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html The downside is that you should probably be proactively checking this list (poll vs ping) and it can sometimes be difficult to figure out why a promotion fails or how to fix it. But this does mean that the archive itself is very rarely broken, and it can be a convenient way to stage package updates that may have effects in parts of the archive you might not be aware of. Cheers, -Barry
Re: python-networkx_1.10-1_amd64.changes ACCEPTED into experimental
On 6 October 2015 at 01:51, 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. > > 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. Hang on a second here. I, like many others, wear multiple hats. The things you listed that I help maintain - mock, testtools, etc - are *not* OpenStack specific. They existed before OpenStack, and likely will exist after. They have other users, particularly mock which is very widely used. Its entirely reasonable to say that known reverse dependencies should be considered when upgrading packages, but that is in no way OpenStack specific - and the release schedule of all of the things you listed is entirely independent of OpenStack. Its one of the defects of the single-version design of the archive that we have this uncontrolled use of new releases of software thats put into it, and - well, thats another discussion. We need to live with it though. So I'm +1 on "Check reverse deps aren't significantly broken before uploading to unstable" as a general principle, not as an OpenStack specific thing. -Rob -- Robert Collins Distinguished Technologist HP Converged Cloud
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 s
Re: python-networkx_1.10-1_amd64.changes ACCEPTED into experimental
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. 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. 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. 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...). 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. Cheers, Thomas Goirand (zigo)
Re: python-networkx_1.10-1_amd64.changes ACCEPTED into experimental
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. Cheers, Michael signature.asc Description: OpenPGP digital signature
Re: python-networkx_1.10-1_amd64.changes ACCEPTED into experimental
On Wed, Sep 30, 2015 at 4:26 PM, Thomas Goirand wrote: > On 09/30/2015 12:45 PM, Sandro Tosi wrote: >> nor is uploading a package just for their own interest and then let >> the maintainer fix the mistakes done. This has happened in the past, >> most of the times with Thomas, that's enough. > > Sandro, > > I've done hundreds of uploads. Lots of them uploading stuff maintained > within the DPMT. So far, only a single person complained... still you have decided to ignore that single person opinion and go on your way... > Also, I don't know how you came to the conclusion that I want to just > let you fix mistakes I did. Should I understand that you agree that I do > another upload of networkx? no it's not, let me paste here my reply to your private msg (it's what I wrote so I dont disclose anything): """ I would appreciate if you could stop committing directly to the packages I maintain; please submit patches to the BTS instead. (this is an implicit nack to the upload) """ > If so, please *more clearly* explain what > you think was wrong, with an exhaustive list of problems you found. As I I wrote that, check CAB4XWXyoPJo91MnyqNRAV=aDP4CGS4H-m5=1jrnc14k_g-c...@mail.gmail.com , it's been tehre for more than a day, you also have replied to part to that msg, but not the technical part > understand, the --exclude when running nose should go away, and a new > dependency should appear instead. Anything else? > > Probably off the list as well, as I'm not sure anyone but you and I > would care to read that. it seems the topic generated quite some replies to other parties, so let's keep it public, shall we? -- Sandro Tosi (aka morph, morpheus, matrixhasu) My website: http://matrixhasu.altervista.org/ Me at Debian: http://wiki.debian.org/SandroTosi
Re: python-networkx_1.10-1_amd64.changes ACCEPTED into experimental
On Wed, Sep 30, 2015 at 4:12 PM, Thomas Goirand wrote: > On 09/30/2015 12:38 PM, Scott Kitterman wrote: >> He knew it violated team norms and just didn't care. > > That's not what I wrote. > > I went into packages.d.o, saw DPMT, and a bit too fast, thought it was > team maintained and that an upload would be accepted. Yes, I knew the > rule, but no I didn't just ignore it. I was just confused by looking too > fast, and seeing DPMT in the package. > > Write the rule into the stones of a policy wont fix it, such mistake may > happen again. you mean taht again you will "look too fast" the maintainer and go on with your agenda? lintian reported W: python-networkx source: changelog-should-mention-nmu W: python-networkx source: source-nmu-has-incorrect-version-number 1.10-1 not even that was an alert for you? -- Sandro Tosi (aka morph, morpheus, matrixhasu) My website: http://matrixhasu.altervista.org/ Me at Debian: http://wiki.debian.org/SandroTosi
Re: python-networkx_1.10-1_amd64.changes ACCEPTED into experimental
On 09/30/2015 05:40 PM, Andrey Rahmatullin wrote: > On Wed, Sep 30, 2015 at 05:26:08PM +0200, Thomas Goirand wrote: >> I've done hundreds of uploads. Lots of them uploading stuff maintained >> within the DPMT. So far, only a single person complained... > That's not really true. Ah, correct, there was you as well with babel... Thomas
Re: python-networkx_1.10-1_amd64.changes ACCEPTED into experimental
On 09/30/2015 11:15 AM, Sandro Tosi wrote: > yeah that's it, you care only about pkg-openstack and has no interest > to be a member of this team No ! > (as it's proved by the fact you keep > uploading general-purposes python modules under pkg-openstak umbrella) This is due to the fact we're not allowed to use Git yet. I already wrote that I would move the packages to DPMT as soon as Git is allowed. Also, I welcome anyone from DPMT to join pkg-openstack if they want to use Git and do team maintenance. Many others did already. Thomas
Re: python-networkx_1.10-1_amd64.changes ACCEPTED into experimental
On Wed, Sep 30, 2015 at 05:26:08PM +0200, Thomas Goirand wrote: > I've done hundreds of uploads. Lots of them uploading stuff maintained > within the DPMT. So far, only a single person complained... That's not really true. -- WBR, wRAR signature.asc Description: PGP signature
Re: python-networkx_1.10-1_amd64.changes ACCEPTED into experimental
On 09/30/2015 12:45 PM, Sandro Tosi wrote: > nor is uploading a package just for their own interest and then let > the maintainer fix the mistakes done. This has happened in the past, > most of the times with Thomas, that's enough. Sandro, I've done hundreds of uploads. Lots of them uploading stuff maintained within the DPMT. So far, only a single person complained... Also, I don't know how you came to the conclusion that I want to just let you fix mistakes I did. Should I understand that you agree that I do another upload of networkx? If so, please *more clearly* explain what you think was wrong, with an exhaustive list of problems you found. As I understand, the --exclude when running nose should go away, and a new dependency should appear instead. Anything else? Probably off the list as well, as I'm not sure anyone but you and I would care to read that. Thomas
Re: python-networkx_1.10-1_amd64.changes ACCEPTED into experimental
On 09/30/2015 11:15 AM, Sandro Tosi wrote: > so long for "Finger-pointing is pointless loss of time for everyone." > just a few lines above.. It wasn't the goal of my 2 examples.
Re: python-networkx_1.10-1_amd64.changes ACCEPTED into experimental
On 09/30/2015 12:38 PM, Scott Kitterman wrote: > He knew it violated team norms and just didn't care. That's not what I wrote. I went into packages.d.o, saw DPMT, and a bit too fast, thought it was team maintained and that an upload would be accepted. Yes, I knew the rule, but no I didn't just ignore it. I was just confused by looking too fast, and seeing DPMT in the package. Write the rule into the stones of a policy wont fix it, such mistake may happen again. Thomas
Re: python-networkx_1.10-1_amd64.changes ACCEPTED into experimental
On Wed, 30 Sep 2015 at 10:45 Thomas Goirand wrote: > On 09/29/2015 04:02 PM, Tristan Seligmann wrote: > > but I'm not sure that having someone > > blindly upload my packages if they haven't worked on them before is a > > good idea. > > If this is what you think of my upload, I don't agree with the above > wording at least. > I don't specifically know anything about networkx, and I didn't take the time to look at it, so I wasn't directing this at you personally except insofar as the events that spawned this thread made me think about situations like this. I think I do owe you an apology as my original mail was worded carelessly. On 09/29/2015 04:02 PM, Tristan Seligmann wrote: > > I feel like I should go through all of my packages and remove the team > > from Maintainer for all of them > > If you don't want anyone from the team to upload "your" packages (btw, > they are not yours, you are sharing them with other DDs and all of our > user bases), then by all means, remove the team from any fields. > They're mine in the sense that I am taking responsibility for them, while others are not. I'm the one reading the bug repoorts, looking at the package on my qa.debian.org dashboard, etc. I'm certainly not opposed (in general) to anyone wants to share that responsibility, but then surely the way to do this is to add themselves to Uploaders? If they're not interested in doing that, then I think it's probably best if I (or another co-maintainer, if there is one!) am at least glancing over their changes before they're uploaded. In other words, I'm not trying to say "MINE! ALL MINE! HANDS OFF!", and in fact I don't mind anyone *committing* things to any of my packages: the worst case scenario there is that I see the changes, find some horrible problem, revert them, and let you know why. I don't think that's a terrible state of affairs at all for a worst case, and most of the time the scenario will be that I see the changes, don't find any horrible problems, and am very happy that someone else did some work so that I didn't have to do it! But I am uncomfortable taking responsibility for a package version that I didn't even have a chance to look at before it was uploaded. On the other hand, I don't want a lack of time/effort to hold up others who can put in the time/effort, that is why I try to make a point out of responding quickly in cases like this; I know how frustrating it can be to have a simple patch blocked for weeks by an unresponsive maintainer, and I definitely don't want my "please don't upload without pinging me" ideas to lead to situations like that. In other words, if I don't have the time to respond quickly, then I'm probably disqualifying myself as a maintainer anyway, so it only makes sense to allow others to take over in my "absence", even if only temporarily.
Re: python-networkx_1.10-1_amd64.changes ACCEPTED into experimental
On September 30, 2015 6:47:57 AM EDT, Sandro Tosi wrote: >On Wed, Sep 30, 2015 at 11:38 AM, Scott Kitterman > wrote: >> I'd much prefer he was spending time reviewing jtaylor's patch to fix >the python-numpy FTBFS on powerpc instead of being distracted by this >argument. > >slightly off topic here, but I plan to look at it and (if successful) >upload numpy this evening BST, i simply dont have the tools/time to do >it now Thanks. It'll be late tonight US east coast time before I can work on the transition, so that'll be perfect if it works out. Ironic that actually fixing stuff is off topic. Scott K
Re: python-networkx_1.10-1_amd64.changes ACCEPTED into experimental
On Wed, Sep 30, 2015 at 11:38 AM, Scott Kitterman wrote: > I'd much prefer he was spending time reviewing jtaylor's patch to fix the > python-numpy FTBFS on powerpc instead of being distracted by this argument. slightly off topic here, but I plan to look at it and (if successful) upload numpy this evening BST, i simply dont have the tools/time to do it now -- Sandro Tosi (aka morph, morpheus, matrixhasu) My website: http://matrixhasu.altervista.org/ Me at Debian: http://wiki.debian.org/SandroTosi
Re: python-networkx_1.10-1_amd64.changes ACCEPTED into experimental
> I see nothing wrong with Goirand's upload. I believe Sandro Tosi is > still using the pre-binNMU, pre-NMU, pre-LowNMU, pre-Team packaging > maintenance mentality which is not the commonly accepted behaviour and > mentality in Debian anymore. this is not a binNMU (which is irrelevant here), nor a NMU (even though lintian warned it was), nor my packages are in lowNMU list (so, again, irrelevant), it is indeed maintained in the DPMT, which has a set of rules called policy. are you asserting that it's perfectly fine to ignore the policy which should bind our work in this team? > Sando, if you don't like something in > particular about a particular upload you should fix those points and > re-upload and e.g. send an email with a diff to the last uploader with > code review and comments. what? so $random_developer arrives, changes the packages, does mistakes, uploads nonetheless, I should happily fix them, and then let them know what was wrong? so why shouldnt that very same $random_developer get in touch with the maintainer who has done the work so far? > Complaining about the maintainer vs uploader > policy does not improve the package in question. nor is uploading a package just for their own interest and then let the maintainer fix the mistakes done. This has happened in the past, most of the times with Thomas, that's enough. > As all uploads - good > and bad - are always done with only best intentions in mind, do take > that into account. Nobody is trying to attack you, your packages, or > somehow sabotage Debian. I dont think you can assert what others' intentions are (even if good faith *can* be assumed), still shielding behind the "team maintenance" to do whatever one pleases is WRONG! stop being apologetic for such behavior. -- Sandro Tosi (aka morph, morpheus, matrixhasu) My website: http://matrixhasu.altervista.org/ Me at Debian: http://wiki.debian.org/SandroTosi
Re: python-networkx_1.10-1_amd64.changes ACCEPTED into experimental
On September 30, 2015 6:27:02 AM EDT, Dimitri John Ledkov wrote: >On 30 September 2015 at 10:26, Thomas Kluyver >wrote: >> On Wed, Sep 30, 2015, at 01:53 AM, Thomas Goirand wrote: >>> 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. >> >> Just to back this up: watching threads like this go past makes >working >> on/with Debian look very uninviting. At times it seems like DPMT is >more >> interested in quoting sections of policy at one another than in >actually >> making stuff work. It looks absolutely like there's no team spirit, >> unless you all keep it carefully hidden from the mailing list. If >this >> is what you're like even to other people with @debian.org email >> addresses, I don't want to try doing anything within Debian. >> >> Thomas K >> > >I see nothing wrong with Goirand's upload. I believe Sandro Tosi is >still using the pre-binNMU, pre-NMU, pre-LowNMU, pre-Team packaging >maintenance mentality which is not the commonly accepted behaviour and >mentality in Debian anymore. Sando, if you don't like something in >particular about a particular upload you should fix those points and >re-upload and e.g. send an email with a diff to the last uploader with >code review and comments. Complaining about the maintainer vs uploader >policy does not improve the package in question. As all uploads - good >and bad - are always done with only best intentions in mind, do take >that into account. Nobody is trying to attack you, your packages, or >somehow sabotage Debian. Nonsense. The upload violated team norms. He knew it violated team norms and just didn't care. I don't think it is appropriate to be attacking Sandro for asking that we work collaboratively. I'd much prefer he was spending time reviewing jtaylor's patch to fix the python-numpy FTBFS on powerpc instead of being distracted by this argument. How about everyone whose considering extending this already excessively long thread consider if what they have to say is so important it's worth blocking the entire python3.5 transition over. If it's not, let's just leave the mail unsent and let's get back to work. Scott K
Re: python-networkx_1.10-1_amd64.changes ACCEPTED into experimental
On 30 September 2015 at 10:26, Thomas Kluyver wrote: > On Wed, Sep 30, 2015, at 01:53 AM, Thomas Goirand wrote: >> 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. > > Just to back this up: watching threads like this go past makes working > on/with Debian look very uninviting. At times it seems like DPMT is more > interested in quoting sections of policy at one another than in actually > making stuff work. It looks absolutely like there's no team spirit, > unless you all keep it carefully hidden from the mailing list. If this > is what you're like even to other people with @debian.org email > addresses, I don't want to try doing anything within Debian. > > Thomas K > I see nothing wrong with Goirand's upload. I believe Sandro Tosi is still using the pre-binNMU, pre-NMU, pre-LowNMU, pre-Team packaging maintenance mentality which is not the commonly accepted behaviour and mentality in Debian anymore. Sando, if you don't like something in particular about a particular upload you should fix those points and re-upload and e.g. send an email with a diff to the last uploader with code review and comments. Complaining about the maintainer vs uploader policy does not improve the package in question. As all uploads - good and bad - are always done with only best intentions in mind, do take that into account. Nobody is trying to attack you, your packages, or somehow sabotage Debian. -- Regards, Dimitri.
Re: python-networkx_1.10-1_amd64.changes ACCEPTED into experimental
On Wed, Sep 30, 2015, at 01:53 AM, Thomas Goirand wrote: > 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. Just to back this up: watching threads like this go past makes working on/with Debian look very uninviting. At times it seems like DPMT is more interested in quoting sections of policy at one another than in actually making stuff work. It looks absolutely like there's no team spirit, unless you all keep it carefully hidden from the mailing list. If this is what you're like even to other people with @debian.org email addresses, I don't want to try doing anything within Debian. Thomas K
Re: python-networkx_1.10-1_amd64.changes ACCEPTED into experimental
On Wed, Sep 30, 2015 at 9:53 AM, Thomas Goirand 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.debia
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)
Re: python-networkx_1.10-1_amd64.changes ACCEPTED into experimental
On 09/29/2015 04:02 PM, Tristan Seligmann wrote: > but I'm not sure that having someone > blindly upload my packages if they haven't worked on them before is a > good idea. If this is what you think of my upload, I don't agree with the above wording at least. On 09/29/2015 04:02 PM, Tristan Seligmann wrote: > I feel like I should go through all of my packages and remove the team > from Maintainer for all of them If you don't want anyone from the team to upload "your" packages (btw, they are not yours, you are sharing them with other DDs and all of our user bases), then by all means, remove the team from any fields. Thomas
Re: python-networkx_1.10-1_amd64.changes ACCEPTED into experimental
On Wed, Sep 30, 2015 at 9:12 AM, Thomas Goirand wrote: > On 09/29/2015 02:11 PM, Sandro Tosi wrote: >>> Are >>> there any specific changes you object to >> >> As for the technical aspects, tests were disabled mentioning they >> access internet (and from the code it is not clear at all if they do, >> and I kinda doubt that) > > It clearly showed access to the outside world when it wasn't blacklisted. really? I re-enabled the test, and this is what I got (pasting and line wrapping will suck): File "/tmp/buildd/python-networkx-1.10/networkx/drawing/nx_agraph.py", line 218, in networkx.drawing.nx_agraph.graphviz_layout Failed example: pos=nx.graphviz_layout(G) Exception raised: Traceback (most recent call last): File "/usr/lib/python2.7/doctest.py", line 1315, in __run compileflags, 1) in test.globs File "", line 1, in pos=nx.graphviz_layout(G) File "/tmp/buildd/python-networkx-1.10/networkx/drawing/nx_pydot.py", line 257, in graphviz_layout return pydot_layout(G=G,prog=prog,root=root,**kwds) File "/tmp/buildd/python-networkx-1.10/networkx/drawing/nx_pydot.py", line 271, in pydot_layout pydot = load_pydot() File "/tmp/buildd/python-networkx-1.10/networkx/drawing/nx_pydot.py", line 47, in load_pydot raise ImportError(msg) ImportError: pydot could not be loaded: http://code.google.com/p/pydot/ is this what you call "clearly showed access"? did you even look at the code? It is just an indication where to download pydot since it cannot be found when running the test disabling the test is *wrong* adding a build-dep is *right*. Fix your mistakes or refrain from changing packages you dont understand or care to maintain. -- Sandro Tosi (aka morph, morpheus, matrixhasu) My website: http://matrixhasu.altervista.org/ Me at Debian: http://wiki.debian.org/SandroTosi
Re: python-networkx_1.10-1_amd64.changes ACCEPTED into experimental
On 09/29/2015 02:11 PM, Sandro Tosi wrote: >> Are >> there any specific changes you object to > > As for the technical aspects, tests were disabled mentioning they > access internet (and from the code it is not clear at all if they do, > and I kinda doubt that) It clearly showed access to the outside world when it wasn't blacklisted. Thomas
Re: python-networkx_1.10-1_amd64.changes ACCEPTED into experimental
Le mardi 29 sept. 2015 à 20:40:11 (+0200), Piotr Ożarowski a écrit : > [Barry Warsaw, 2015-09-29] > > On Sep 29, 2015, at 05:40 PM, Julien Puydt wrote: > > > > >- I want lintian not to bug me about NMU ; > > > > This one's easy. Just put "Team upload" in the changelog (e.g. `dch > > --team`). > > it's even easier than that... add yourself to Uploaders (you're > maintaining it after all!) Yes, that's what I said: I put myself as uploaders so lintian doesn't bug me about NMU. Snark on #debian-python
Re: python-networkx_1.10-1_amd64.changes ACCEPTED into experimental
[Barry Warsaw, 2015-09-29] > On Sep 29, 2015, at 05:40 PM, Julien Puydt wrote: > > >- I want lintian not to bug me about NMU ; > > This one's easy. Just put "Team upload" in the changelog (e.g. `dch --team`). it's even easier than that... add yourself to Uploaders (you're maintaining it after all!) -- Piotr Ożarowski Debian GNU/Linux Developer www.ozarowski.pl www.griffith.cc www.debian.org GPG Fingerprint: 1D2F A898 58DA AF62 1786 2DF7 AEF6 F1A2 A745 7645
Re: python-networkx_1.10-1_amd64.changes ACCEPTED into experimental
On Sep 29, 2015, at 05:40 PM, Julien Puydt wrote: >- I want lintian not to bug me about NMU ; This one's easy. Just put "Team upload" in the changelog (e.g. `dch --team`). Cheers, -Barry
Re: python-networkx_1.10-1_amd64.changes ACCEPTED into experimental
Hi, Le mardi 29 sept. 2015 à 09:48:16 (-0400), Barry Warsaw a écrit : > 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. > > Policy doesn't really spell out the operational differences for when the team > is Maintainer vs. Uploader, and the wiki page explicitly says it's an > *unwritten* policy (despite the fact that putting it in the wiki probably > qualifies as "written" :). How should the change be acknowledged by the > maintainer? Should I Cc the mailing list when I contact the maintainer? Is > it okay to commit to vcs but not upload? How long do you wait for feedback > before you can do the upload? I'm just a DM, but I'm still in the team, so I think I can state my opinion, and explain how I would do things. First thing, report a bug on the package (request for a new version, for example). Wait. Provide patches. Wait. Second, contact the maintainer off list&bug. Wait. Third, contact the list and put the maintainer in CC, stating that things don't get further fast enough and you would like the team to get involved. Wait. Fourth, if the maintainer hasn't answered, then proceed with an RFS or upload (depending on whether one is DD or DM). > (Aside: git! I would love to be able to commit and push a branch and then ask > for the maintainer to review, merge, and upload - or give me the green light > to go ahead.) I create all my packages in git -- that's what the debian-science team uses. And I consider the fact that a package is subversion-maintained a hindrance. > Should we have some automated tools to help out here? I'm not sure where to > hook in such a tool, but if for example when I build a source package, I got a > nice little lintian-like warning saying "The package is team uploadable but > not team maintained, did you give the maintainer time to respond to your > issue?" Something like that would go a long way toward mitigating accidental > or careless toe-stepping. Oh dear, another lintian output to bother me! And don't call that a "warning", some sensitive people prefer the word "tag" :-P > Do all team members understand the implications when they set the two fields? > Some maintainers may not really care and may have been less conscientious > about setting the fields. I definitely didn't really understand the implications. I put the DPMT as maintainer and myself as uploader because : - I want lintian not to bug me about NMU ; - I want to make clear I won't consider people are stepping on my toes if they start helping with a package. Cheers, Snark on #debian-python
Re: python-networkx_1.10-1_amd64.changes ACCEPTED into experimental
On Sep 29, 2015, at 02:02 PM, Tristan Seligmann wrote: >After reading this thread, I feel like I should go through all of my >packages and remove the team from Maintainer for all of them. I try very >hard to respond promptly to pings (bugs, email, IRC, ...) about my >packages, even if it's just to say "sorry, I can't take care of that right >now, feel free to upload"; but I'm not sure that having someone blindly >upload my packages if they haven't worked on them before is a good idea. I'm willing to deal with some honest mistakes with my packages in order to foster a vibrant and active community. I am happy to answer questions about my packages, but I feel spoiled by how nicely things work as an upstream with code hosting sites like GitLab. If we had merge requests, online and email reviews, one-click auto-merge (and uploads!) I think we'd have a better team collaboration workflow. Even post-commit/upload emailed diffs would at least let me review changes after the fact, so I could repair things if I noticed a big problem. Cheers, -Barry
Re: python-networkx_1.10-1_amd64.changes ACCEPTED into experimental
On Tue, 29 Sep 2015 at 15:48 Barry Warsaw wrote: > The wiki says that the general rule of thumb is to set the team as > Maintainer, > to which I agree. I may not have been as deliberate about my own > packages, so > I plan on reviewing them, and will fix any that aren't "special". > After reading this thread, I feel like I should go through all of my packages and remove the team from Maintainer for all of them. I try very hard to respond promptly to pings (bugs, email, IRC, ...) about my packages, even if it's just to say "sorry, I can't take care of that right now, feel free to upload"; but I'm not sure that having someone blindly upload my packages if they haven't worked on them before is a good idea. (And I say this having done a few team uploads in DPMT / collab-maint recently; while I didn't think too much about these at the time, in retrospect I feel like I made a mistake uploading those packages)
Re: python-networkx_1.10-1_amd64.changes ACCEPTED into experimental
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. Policy doesn't really spell out the operational differences for when the team is Maintainer vs. Uploader, and the wiki page explicitly says it's an *unwritten* policy (despite the fact that putting it in the wiki probably qualifies as "written" :). How should the change be acknowledged by the maintainer? Should I Cc the mailing list when I contact the maintainer? Is it okay to commit to vcs but not upload? How long do you wait for feedback before you can do the upload? (Aside: git! I would love to be able to commit and push a branch and then ask for the maintainer to review, merge, and upload - or give me the green light to go ahead.) Should we have some automated tools to help out here? I'm not sure where to hook in such a tool, but if for example when I build a source package, I got a nice little lintian-like warning saying "The package is team uploadable but not team maintained, did you give the maintainer time to respond to your issue?" Something like that would go a long way toward mitigating accidental or careless toe-stepping. Do all team members understand the implications when they set the two fields? Some maintainers may not really care and may have been less conscientious about setting the fields. The wiki says that the general rule of thumb is to set the team as Maintainer, to which I agree. I may not have been as deliberate about my own packages, so I plan on reviewing them, and will fix any that aren't "special". Cheers, -Barry
Re: python-networkx_1.10-1_amd64.changes ACCEPTED into experimental
On September 29, 2015 7:55:36 AM EDT, Julien Cristau wrote: >On Tue, Sep 29, 2015 at 12:26:44 +0100, Sandro Tosi wrote: > >> Once again, the python policy about Maintainer/Uploaders has been >ignored >> >> >http://python-modules.alioth.debian.org/python-modules-policy.html#maintainership >> https://wiki.debian.org/Teams/PythonModulesTeam/HowToJoin >> >> either policy changes or this has to stop at some point. >> >OTOH, this is experimental. It's not like this upload has any effect >on >anyone except to let Thomas work on packages that depend on it. Are >there any specific changes you object to, and that can't be easily >reverted before an upload to unstable? It's also not much effort to do a bit of coordination with the team. The technical impact of this kind of antisocial behavior is, IMO, secondary. Scott K
Re: python-networkx_1.10-1_amd64.changes ACCEPTED into experimental
> OTOH, this is experimental. It's not like this upload has any effect on > anyone except to let Thomas work on packages that depend on it. still the policy defines a set of rules that apply to any debian suites, or are you suggesting that experimental is not cover by those rules and we could do whatever we want? The bug asking for a new version was issues 2 hours before the upload with urgency wishlist, without mentioning it was a blocker for anything. > Are > there any specific changes you object to As for the technical aspects, tests were disabled mentioning they access internet (and from the code it is not clear at all if they do, and I kinda doubt that), the test suite for py3k fails with 'FAILED (SKIP=17, errors=69, failures=13)' halting the build in my clean pbuilder env, the doc requirements list "sphinxcontrib-bibtex" which is not yet in debian (the reason I halted the upgrade myself sometime ago) so I'm not sure how the doc could have been built + all the time I wasted having to write this >, and that can't be easily > reverted before an upload to unstable? I dont know if I understand correctly: are you saying that, since he needed that package updated he could technical sub-optimal work, and then let the maintainer/somebody else fix what's left broken? because that's what's going to happen :( (python3-memcache anyone?) -- Sandro Tosi (aka morph, morpheus, matrixhasu) My website: http://matrixhasu.altervista.org/ Me at Debian: http://wiki.debian.org/SandroTosi
Re: python-networkx_1.10-1_amd64.changes ACCEPTED into experimental
On Tue, Sep 29, 2015 at 12:26:44 +0100, Sandro Tosi wrote: > Once again, the python policy about Maintainer/Uploaders has been ignored > > http://python-modules.alioth.debian.org/python-modules-policy.html#maintainership > https://wiki.debian.org/Teams/PythonModulesTeam/HowToJoin > > either policy changes or this has to stop at some point. > OTOH, this is experimental. It's not like this upload has any effect on anyone except to let Thomas work on packages that depend on it. Are there any specific changes you object to, and that can't be easily reverted before an upload to unstable? Cheers, Julien -- Julien Cristau Logilab http://www.logilab.fr/ Informatique scientifique & gestion de connaissances
Re: python-networkx_1.10-1_amd64.changes ACCEPTED into experimental
[Sandro Tosi, 2015-09-29] > Once again, the python policy about Maintainer/Uploaders has been ignored > > http://python-modules.alioth.debian.org/python-modules-policy.html#maintainership > https://wiki.debian.org/Teams/PythonModulesTeam/HowToJoin > > either policy changes or this has to stop at some point. it still applies and I will start removing people from DPMT / PAPT who do not follow it. -- Piotr Ożarowski Debian GNU/Linux Developer www.ozarowski.pl www.griffith.cc www.debian.org GPG Fingerprint: 1D2F A898 58DA AF62 1786 2DF7 AEF6 F1A2 A745 7645
Re: python-networkx_1.10-1_amd64.changes ACCEPTED into experimental
Once again, the python policy about Maintainer/Uploaders has been ignored http://python-modules.alioth.debian.org/python-modules-policy.html#maintainership https://wiki.debian.org/Teams/PythonModulesTeam/HowToJoin either policy changes or this has to stop at some point. On Tue, Sep 29, 2015 at 12:19 PM, Debian FTP Masters wrote: > > > Accepted: > > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > Format: 1.8 > Date: Wed, 02 Sep 2015 13:17:15 + > Source: python-networkx > Binary: python-networkx python3-networkx python-networkx-doc > Architecture: source all > Version: 1.10-1 > Distribution: experimental > Urgency: medium > Maintainer: Sandro Tosi > Changed-By: Thomas Goirand > Description: > python-networkx - tool to create, manipulate and study complex networks > python-networkx-doc - tool to create, manipulate and study complex networks > - documenta > python3-networkx - tool to create, manipulate and study complex networks > (Python3) > Closes: 800431 > Changes: > python-networkx (1.10-1) experimental; urgency=medium > . >[ Sandro Tosi ] >* New upstream release (Closes: #800431). > . >[ Thomas Goirand ] >* Move to Build-Depends: what was in Build-Depends-Indep: but which is > needed > for the clean target. >* Dropped version of packages for those already provided in Jessie. >* Removed now useless python-3.4.patch patch from Chuck Short. >* Removed do-not-use-sphinx_rtd_theme.patch patch. Build-Depends on the > python-sphinx-rtd-theme package instead. >* Exclude tests which are doing internet access and failing. >* Do not rename non-existing README file. > Checksums-Sha1: > 43b217e9bfc7a180822f6bb72c507670fc4161b6 2550 python-networkx_1.10-1.dsc > 99292e464c25be5e96de295752880bf5e5f1848a 1189291 > python-networkx_1.10.orig.tar.gz > 1ec58c43a77675987a4c087f4034de393a8c31e6 187972 > python-networkx_1.10-1.debian.tar.xz > 858a5824f6ff6e20182d0b572319933485498c48 4483016 > python-networkx-doc_1.10-1_all.deb > ac050975613a620d1acb5b2a6e12f1d69dec34c6 820962 > python-networkx_1.10-1_all.deb > f6feb64baa117e593b1ad7a90f782fbc361b1bf8 621436 > python3-networkx_1.10-1_all.deb > Checksums-Sha256: > c25abfa8a95bcad43df30823b89e3d676674d00ec9d60c2c0e24165ac43ea710 2550 > python-networkx_1.10-1.dsc > ced4095ab83b7451cec1172183eff419ed32e21397ea4e1971d92a5808ed6fb8 1189291 > python-networkx_1.10.orig.tar.gz > b0ce586bcb110d276e6195c6dc9448f1aa7c30e1172d79053abf7e296f68030f 187972 > python-networkx_1.10-1.debian.tar.xz > f1f064fc93d9532743536474cdf4fce24e46599f74c79256461b4c4e17a19bda 4483016 > python-networkx-doc_1.10-1_all.deb > 280b30027e3d3f36e83d1bee434a456db80553e697e4ff21a399b136d2a7568e 820962 > python-networkx_1.10-1_all.deb > 6c615e4a23a98d62215bb49ba2746ce7111ba3fd53e2ef06f0f2a1b876f3ab54 621436 > python3-networkx_1.10-1_all.deb > Files: > 478146aafb466aa4480002d8e0283e56 2550 python optional > python-networkx_1.10-1.dsc > eb7a065e37250a4cc009919dacfe7a9d 1189291 python optional > python-networkx_1.10.orig.tar.gz > 7fc5a2a7210482fd793b5567a56e5471 187972 python optional > python-networkx_1.10-1.debian.tar.xz > c92c6f60db8e58f5964e640917503960 4483016 doc optional > python-networkx-doc_1.10-1_all.deb > 90fce4157d27999dde4bd61db1e46c7f 820962 python optional > python-networkx_1.10-1_all.deb > c1e4b687e06e67fea72228d29a17372b 621436 python optional > python3-networkx_1.10-1_all.deb > > -BEGIN PGP SIGNATURE- > Version: GnuPG v1 > > iQIcBAEBCAAGBQJWCm7EAAoJENQWrRWsa0P+Bj8QAIlac+W7xs6l+1PmSCUOUmLI > qGH3HOHfDX+9uFCa1ILz41K2OnP8F54o9SAdHLY+ckdGXoSTNT//SlqalrfUwEfi > DXstqVfZGzgsJSh/a4cF4eutWRdEZeCcVGzhJvvZV5icIheRujEkD22BDPerw1fH > kIPzYnV9dKWGS7xf5gLEHivhu2GloazSMFDrCSF2jE+e1sAoQvpbuquxLfBS0xVg > 3kfDYIIXv3JV5WReETF/kN5us2eA34L4dAzehqe1+LLR9WEsjNTVCe7nuSV1/eyA > +R+wsPRlZNVlzuWz2ieshVL3BXD8EWf9jC2mYinIQhC+VxWLC0qNTNRE7JE4n+Gu > JJU2YvXLOIRHyld7EjYBrYqeZkz+buQ2Q036R5TQN4PH3H1jZKUrKhUdnBNgAf3Y > YqoactuiZyCvRjMSnsFzsr6hwjpvpHVgJkUDgfFTiJtVQDO/371VzJwtoPrXV4yI > obOD4MaW9n3afxF5NRRDZa2Nq8RRPAlNFu+u7sLrIvlUVe5ERSb7GnGWWAeNAF02 > okm8s9HVNZbs6BUoa8hz37OfyPc5AOW3XpOn1libP2JVW6+0Ah6/mU9fq56dOP5o > nVbMSC74MMy6xLmi3jBVk4ChQg2MwaXQzik55U6JW5MK3P9s6Sq0A67Zs+fuyE3M > GYO+p3rg2WMFx0SdeWjH > =ir36 > -END PGP SIGNATURE- > > > Thank you for your contribution to Debian. -- Sandro Tosi (aka morph, morpheus, matrixhasu) My website: http://matrixhasu.altervista.org/ Me at Debian: http://wiki.debian.org/SandroTosi
