Re: I've been removed from the Python team
[Pierre-Elliott Bécue, 2015-10-01] > Even if I'm not in the team and thus I do not decide of anything, I > wonder if that's an appropriate answer, regarding the initial trouble. > > We are currently talking about preventing Thomas to maintain his > packages that has DPMT as maintainer, because he uploaded something in which packages? All of them are in OpenStack team and few that list Thomas as co-maintainer have other maintainers who can commit changes. > experimental, which is neither a release, nor a distro of any kind. I would not remove someone due to technical mistake (or several made not on purpose) - that's not the case here. I did that because I see no hope in change of behaviour (and I was warned about it from day one and I *did* try to change it several times). There's something good that comes out of it, though: I was afraid to accept new members after two that caused more harm than good and now I have solution to that problem: everyone who wants to be in the team, automatically is! Yes, from now on we will not (or at least I will not) stop you from contributing if you don't have write access. No more "you cannot contribute, stay away, do not send patches" policy! Every new member can now send commits to me and I will push them to the repo (both svn/git and unstable). If you want write access, just bombard me with commits to review (the same way my sponsorees force me to ask them to join NM queue - just send contribution and learn from problems I pointed out). Thomas is the first person I asked to do that. -- 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 signature.asc Description: Digital signature
Re: I've been removed from the Python team
Hi Pierre-Elliott, On Thu, Oct 01, 2015 at 12:04:14AM +0200, Pierre-Elliott Bécue wrote: > On mer. 30 sept. 2015 à 23:13:26, Piotr Ożarowski wrote: > > [Thomas Goirand, 2015-09-30] > > > Piotr decided to remove me from the Python team. > > DPMT and PAPT to be precise, yes > > > is an over reaction and that it should be reverted. > > I talked with you many times in private about your involvement in the > > teams over last ~3 years and since I kind of forced other admins into > > accepting you, I also take all the blame for removing you. > > As I said in the private mail earlier today, if you still want to work > > with me, I'm happy to review / sponsor your commits in DPMT or help with > > any problems you might have with tools I wrote. > Even if I'm not in the team and thus I do not decide of anything, I > wonder if that's an appropriate answer, regarding the initial trouble. > We are currently talking about preventing Thomas to maintain his > packages that has DPMT as maintainer, because he uploaded something in > experimental, which is neither a release, nor a distro of any kind. It's not my place to judge whether this was a correct disciplinary action for the DPMT, of which I am not a member; but for the record, this does not in any way prevent Thomas from continuing to maintain *his* packages. The DPMT doesn't block a maintainer from moving their packages out of the DPMT repositories and maintaining them elsewhere. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Re: I've been removed from the Python team
On September 30, 2015 6:43:09 PM EDT, "Pierre-Elliott Bécue" wrote: >Le 1 octobre 2015 00:25:55 GMT+02:00, Ian Cordasco > a écrit : >>On Wed, Sep 30, 2015 at 5:04 PM, Pierre-Elliott Bécue > >>wrote: >>> On mer. 30 sept. 2015 à 23:13:26, Piotr Ożarowski wrote: [Thomas Goirand, 2015-09-30] > Piotr decided to remove me from the Python team. DPMT and PAPT to be precise, yes > is an over reaction and that it should be reverted. I talked with you many times in private about your involvement in >>the teams over last ~3 years and since I kind of forced other admins >>into accepting you, I also take all the blame for removing you. As I said in the private mail earlier today, if you still want to >>work with me, I'm happy to review / sponsor your commits in DPMT or help >>with any problems you might have with tools I wrote. >>> >>> Dear Piotr, >>> >>> Even if I'm not in the team and thus I do not decide of anything, I >>> wonder if that's an appropriate answer, regarding the initial >>trouble. >>> >>> We are currently talking about preventing Thomas to maintain his >>> packages that has DPMT as maintainer, because he uploaded something >>in >>> experimental, which is neither a release, nor a distro of any kind. >>> >>> Considering the potential trouble it'll lead to (as for an example >>it'll >>> probably send my attempt to package mailman3 to nowhere), and the >>> potential bad consequences for python team (some packages no longer >>> maintained, etc), does it worth it? >>> >>> -- >>> PEB >> >>Pierre, >> >>I'm new to the team, mailing list, etc. (honestly, I never had a >>chance to formally introduce myself to everyone) but it looks as if >>Piotr has had several instances in the past where he's had to >>discipline Thomas. I doubt this is an action that Piotr took lightly. >>Further, I doubt those packages will suddenly go unmaintained. >> >>Please continue working on mailman3, it will benefit the community far >>more than the outcome of this apparent disciplinary action. >> >>Cheers, >>Ian > >Dear Ian, > >I do not intend to stop working on it, but even if it is not the first >time (I hope no one would take such an action for one isolated >mistake), I strongly beleive that such removal from a team where mostly >anyone is supposed to be at a same level should be calmly discussed and >debated with mostly everybody of the team in order to reach a >consensus. > >This decision looks like something decided just after an aggressive >discussion about something which does not look that bad from where I >sit. > >Wouldn't taking some time to think before this removal had been a >better idea for everybody? Not really. Speaking as one of the team's other admins (even though p1otr has taken this all on himself), I fully support the action. I agree it's unfortunate that it came to this, but I believe that, for now, it's for the best. If we're going to work as a team, then there has to be collaboration and a willingness to work within team norms. Don't just judge this one case. I believe it's best if Thomas takes a break from the team. If he's ever going to be a part of it in the future, he's going to have to be more collaborative. I'm not going to get in a long debate, but there comes a time in any volunteer group when you have to decide to cut your losses. Hopefully we get this sorted after a short break from the team. Scott K
Re: I've been removed from the Python team
Le 1 octobre 2015 00:25:55 GMT+02:00, Ian Cordasco a écrit : >On Wed, Sep 30, 2015 at 5:04 PM, Pierre-Elliott Bécue >wrote: >> On mer. 30 sept. 2015 à 23:13:26, Piotr Ożarowski wrote: >>> [Thomas Goirand, 2015-09-30] >>> > Piotr decided to remove me from the Python team. >>> >>> DPMT and PAPT to be precise, yes >>> >>> > is an over reaction and that it should be reverted. >>> >>> I talked with you many times in private about your involvement in >the >>> teams over last ~3 years and since I kind of forced other admins >into >>> accepting you, I also take all the blame for removing you. >>> As I said in the private mail earlier today, if you still want to >work >>> with me, I'm happy to review / sponsor your commits in DPMT or help >with >>> any problems you might have with tools I wrote. >> >> Dear Piotr, >> >> Even if I'm not in the team and thus I do not decide of anything, I >> wonder if that's an appropriate answer, regarding the initial >trouble. >> >> We are currently talking about preventing Thomas to maintain his >> packages that has DPMT as maintainer, because he uploaded something >in >> experimental, which is neither a release, nor a distro of any kind. >> >> Considering the potential trouble it'll lead to (as for an example >it'll >> probably send my attempt to package mailman3 to nowhere), and the >> potential bad consequences for python team (some packages no longer >> maintained, etc), does it worth it? >> >> -- >> PEB > >Pierre, > >I'm new to the team, mailing list, etc. (honestly, I never had a >chance to formally introduce myself to everyone) but it looks as if >Piotr has had several instances in the past where he's had to >discipline Thomas. I doubt this is an action that Piotr took lightly. >Further, I doubt those packages will suddenly go unmaintained. > >Please continue working on mailman3, it will benefit the community far >more than the outcome of this apparent disciplinary action. > >Cheers, >Ian Dear Ian, I do not intend to stop working on it, but even if it is not the first time (I hope no one would take such an action for one isolated mistake), I strongly beleive that such removal from a team where mostly anyone is supposed to be at a same level should be calmly discussed and debated with mostly everybody of the team in order to reach a consensus. This decision looks like something decided just after an aggressive discussion about something which does not look that bad from where I sit. Wouldn't taking some time to think before this removal had been a better idea for everybody? Peace, love and cheers. -- PEB
Re: I've been removed from the Python team
On Wed, Sep 30, 2015 at 5:04 PM, Pierre-Elliott Bécue wrote: > On mer. 30 sept. 2015 à 23:13:26, Piotr Ożarowski wrote: >> [Thomas Goirand, 2015-09-30] >> > Piotr decided to remove me from the Python team. >> >> DPMT and PAPT to be precise, yes >> >> > is an over reaction and that it should be reverted. >> >> I talked with you many times in private about your involvement in the >> teams over last ~3 years and since I kind of forced other admins into >> accepting you, I also take all the blame for removing you. >> As I said in the private mail earlier today, if you still want to work >> with me, I'm happy to review / sponsor your commits in DPMT or help with >> any problems you might have with tools I wrote. > > Dear Piotr, > > Even if I'm not in the team and thus I do not decide of anything, I > wonder if that's an appropriate answer, regarding the initial trouble. > > We are currently talking about preventing Thomas to maintain his > packages that has DPMT as maintainer, because he uploaded something in > experimental, which is neither a release, nor a distro of any kind. > > Considering the potential trouble it'll lead to (as for an example it'll > probably send my attempt to package mailman3 to nowhere), and the > potential bad consequences for python team (some packages no longer > maintained, etc), does it worth it? > > -- > PEB Pierre, I'm new to the team, mailing list, etc. (honestly, I never had a chance to formally introduce myself to everyone) but it looks as if Piotr has had several instances in the past where he's had to discipline Thomas. I doubt this is an action that Piotr took lightly. Further, I doubt those packages will suddenly go unmaintained. Please continue working on mailman3, it will benefit the community far more than the outcome of this apparent disciplinary action. Cheers, Ian
Re: I've been removed from the Python team
On mer. 30 sept. 2015 à 23:13:26, Piotr Ożarowski wrote: > [Thomas Goirand, 2015-09-30] > > Piotr decided to remove me from the Python team. > > DPMT and PAPT to be precise, yes > > > is an over reaction and that it should be reverted. > > I talked with you many times in private about your involvement in the > teams over last ~3 years and since I kind of forced other admins into > accepting you, I also take all the blame for removing you. > As I said in the private mail earlier today, if you still want to work > with me, I'm happy to review / sponsor your commits in DPMT or help with > any problems you might have with tools I wrote. Dear Piotr, Even if I'm not in the team and thus I do not decide of anything, I wonder if that's an appropriate answer, regarding the initial trouble. We are currently talking about preventing Thomas to maintain his packages that has DPMT as maintainer, because he uploaded something in experimental, which is neither a release, nor a distro of any kind. Considering the potential trouble it'll lead to (as for an example it'll probably send my attempt to package mailman3 to nowhere), and the potential bad consequences for python team (some packages no longer maintained, etc), does it worth it? -- PEB signature.asc Description: Digital signature
Re: I've been removed from the Python team
[Thomas Goirand, 2015-09-30] > Piotr decided to remove me from the Python team. DPMT and PAPT to be precise, yes > is an over reaction and that it should be reverted. I talked with you many times in private about your involvement in the teams over last ~3 years and since I kind of forced other admins into accepting you, I also take all the blame for removing you. As I said in the private mail earlier today, if you still want to work with me, I'm happy to review / sponsor your commits in DPMT or help with any problems you might have with 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 signature.asc Description: Digital signature
Re: I've been removed from the Python team
On 09/30/2015 09:49 PM, Matthias Klose wrote: > kindergarten ... Indeed. We all have better things to do! Thomas
Re: I've been removed from the Python team
kindergarten ... On 30.09.2015 21:41, Thomas Goirand wrote: Hi, Piotr decided to remove me from the Python team. Those who don't agree (especially admins) please voice your concern. It is my view that this is an over reaction and that it should be reverted. Thomas Goirand (zigo)
I've been removed from the Python team
Hi, Piotr decided to remove me from the Python team. Those who don't agree (especially admins) please voice your concern. It is my view that this is an over reaction and that it should be reverted. Thomas Goirand (zigo)
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.
RFS updating the setuptools-scm and mistune packages
Hi, I made the following changes to both setuptools-scm and mistune : * New upstream release. * Switch maintainership from DPMT to myself. Those packages both have their previous versions in testing+unstable. They are available from here: ssh://git.debian.org/git/python-modules/packages/mistune.git ssh://git.debian.org/git/python-modules/packages/setuptools-scm.git (I didn't tag & dch -r in case a sponsor finds something to change) Thanks, Snark on #debian-python
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: Maintainer vs. Uploaders
On Tue, Sep 29, 2015 at 3:30 PM, Piotr Ożarowski wrote: > [Barry Warsaw, 2015-09-29] >> How should the change be acknowledged by the >> maintainer? Should I Cc the mailing list when I contact the maintainer? Is > > do we really need a written policy how to contact fellow co-maintainer? > Ping on IRC, send an email, send a message via xmpp or phone, ... use > whatever you usually use to contact any other Debian maintainer. > > An example message: > "I just commited some changes in foo related to bar. Please take a look, > I plan to upload it to unstable in a day or two. Let me know if I should > wait a bit longer or if you're not OK with these changes. Thanks" > > I think such message to all Uploaders who clearly know more about given > package than I do is a good practice even if team is listed in > Maintainer field. I don't think sending such message after fixing a typo > is needed, but it's definitely a must when someone replaces dh with > cdbs or vice versa. > >> it okay to commit to vcs but not upload? How long do you wait for feedback >> before you can do the upload? > > yes, it's always OK to commit changes (which can be reverted). It's not OK > to force someone else to maintain these changes by uploading it. > >> Should we have some automated tools to help out here? I'm not sure where to > > no, we already have -commits mailing list which nobody reads. Yet > another reason why team should be in Uploaders and not in Maintainer > field. > >> 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. > > Maintainer vs Uploaders rules needs to be moved to policy. I will > propose a patch to the policy soon (I'd prefer a native speaker to do > it, though) > >> The wiki says that the general rule of thumb is to set the team as >> Maintainer, >> to which I agree. > > I don't (due to "package and forget" issue) +1 on everything you wrote -- 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 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