Re: python-networkx_1.10-1_amd64.changes ACCEPTED into experimental

[Thomas Goirand]

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

[Thomas Goirand]

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

[Thomas Goirand]

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

[Sandro Tosi]

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: I've been removed from the Python team

[Matthias Klose]

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)

Re: I've been removed from the Python team

[Thomas Goirand]

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

[Piotr Ożarowski]

[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

I've been removed from the Python team

[Thomas Goirand]

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

[Thomas Kluyver]

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

[Sandro Tosi]

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

[Dimitri John Ledkov]

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

[Sandro Tosi]

> 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

[Scott Kitterman]

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

[Sandro Tosi]

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: 

RFS updating the setuptools-scm and mistune packages

[Julien Puydt]

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

[Scott Kitterman]

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: Maintainer vs. Uploaders

[Sandro Tosi]

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

[Tristan Seligmann]

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: I've been removed from the Python team

[Ian Cordasco]

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

[Pierre-Elliott Bécue]

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

[Scott Kitterman]

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

[Steve Langasek]

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

[Pierre-Elliott Bécue]

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: python-networkx_1.10-1_amd64.changes ACCEPTED into experimental

[Sandro Tosi]

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

[Sandro Tosi]

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

[Thomas Goirand]

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

[Andrey Rahmatullin]

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

[Thomas Goirand]

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

[Thomas Goirand]

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

[Thomas Goirand]

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

[Thomas Goirand]

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.