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

2015-10-07 Thread Piotr Ożarowski
[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

2015-10-07 Thread Brian May
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

2015-10-07 Thread Thomas Goirand
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: managing transitions (was: python-networkx_1.10-1_amd64.changes ACCEPTED into experimental)

2015-10-06 Thread Barry Warsaw
On Oct 06, 2015, at 08:39 AM, Brian May wrote:

>On Tue, 6 Oct 2015 at 18:46 Thomas Goirand  wrote:
>
>> This IMO is the same topic as having a Gerrit review system (and not
>> just Git) which could do tests on each change of a package even before
>> having them committed to our git.
>>
>
>Sounds like an interesting thing to discuss/test after we move to git...

I don't intend to bikeshed this, nor do I have time to do the work, so in our
do-it-ocracy any online review system would be a fantastic addition.  I'll
just point to GitLab community edition as a nice open source option in this
space.

Cheers,
-Barry



Re: mock 1.2 breaking tests (was: python-networkx_1.10-1_amd64.changes ACCEPTED into experimental)

2015-10-06 Thread Ian Cordasco
On Tue, Oct 6, 2015 at 8:53 AM, Jeremy Stanley  wrote:
> On 2015-10-06 09:28:56 +0200 (+0200), Thomas Goirand wrote:
>> Master != kilo. It still means that I have to do all of the backport
>> work by myself.
> [...]
>> I know that it's the common assumption that, as the package maintainer
>> in Debian, I should volunteer to fix any issue in the 6+ million lines
>> of code in OpenStack ! :)
>>
>> I do try to fix things when I can. But unfortunately, this doesn't scale
>> well enough... In this particular case, it was really too much work.
>
> That is the trade-off you make by choosing to maintain as many
> packages as you do. You can obviously either spend time contributing
> stable backports upstream or time packaging software. Just accept
> that, as with Debian itself, "stable" means OpenStack upstream makes
> the bare minimum alterations necessary. This includes, in some
> cases, continuing to test the software in those branches with
> dependencies which were contemporary to the corresponding releases
> rather than chasing ever changing behavior in them. Sometimes it is
> done for expediency due to lack of interested volunteer effort, and
> sometimes out of necessity because dependencies may simply conflict
> in unresolvable ways.

And to be fair, this has been discussed many times on the mailing list
with you Thomas. The ratio of cores to stable maintenance cores is
probably something upwards of 5:1. Most of the latter group are also
members of the former group which means they have double the
responsibility (if not more, because stable maintenance is a lot more
involved than a place on the regular core reviewer team). The reality
is that stable packages relying on versions that were contemporary at
the time of their release is very very reasonable (and that's how,
e.g., stable linux distros work). After all "stable" is just the name
for "broken in ways we know about", otherwise one would call it
"perfect" for being forever in a working state under all unexpected
conditions (which no piece of software really is).



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

2015-10-06 Thread Thomas Goirand
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

2015-10-06 Thread Thomas Goirand
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: mock 1.2 breaking tests (was: python-networkx_1.10-1_amd64.changes ACCEPTED into experimental)

2015-10-06 Thread Thomas Goirand
On 10/06/2015 02:49 AM, Jeremy Stanley wrote:
> 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.

Master != kilo. It still means that I have to do all of the backport
work by myself. Or are you suggesting that I package from trunk in Sid?
Or that backports of such fixes were available? If the later, then I
missed it.

> 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).

I know that it's the common assumption that, as the package maintainer
in Debian, I should volunteer to fix any issue in the 6+ million lines
of code in OpenStack ! :)

I do try to fix things when I can. But unfortunately, this doesn't scale
well enough... In this particular case, it was really too much work.

Thomas Goirand (zigo)



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

2015-10-06 Thread Thomas Goirand
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

2015-10-06 Thread Piotr Ożarowski
[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: managing transitions (was: python-networkx_1.10-1_amd64.changes ACCEPTED into experimental)

2015-10-06 Thread Thomas Goirand
On 10/05/2015 11:11 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_excuses.html

Oh, nice! We do need something like this too.

> 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.

It's a super nice tool, though in some cases, I do see that we may want
to ignore it. For example, dozens of packages passing, and just a single
leaf one with some issues.

> 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.

If we need the compute power to do it, I have a few proposal for that.
I'm all for having a CI / CD also for packages.

This IMO is the same topic as having a Gerrit review system (and not
just Git) which could do tests on each change of a package even before
having them committed to our git.

Thomas



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

2015-10-06 Thread Ben Finney
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: managing transitions (was: python-networkx_1.10-1_amd64.changes ACCEPTED into experimental)

2015-10-06 Thread Brian May
On Tue, 6 Oct 2015 at 18:46 Thomas Goirand  wrote:

> This IMO is the same topic as having a Gerrit review system (and not
> just Git) which could do tests on each change of a package even before
> having them committed to our git.
>

Sounds like an interesting thing to discuss/test after we move to git...


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

2015-10-06 Thread Thomas Goirand
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: managing transitions (was: python-networkx_1.10-1_amd64.changes ACCEPTED into experimental)

2015-10-06 Thread Mattia Rizzolo
On Tue, Oct 06, 2015 at 08:39:48AM +, Brian May wrote:
> On Tue, 6 Oct 2015 at 18:46 Thomas Goirand  wrote:
> 
> > This IMO is the same topic as having a Gerrit review system (and not
> > just Git) which could do tests on each change of a package even before
> > having them committed to our git.
> >
> 
> Sounds like an interesting thing to discuss/test after we move to git...

Moreover, jenkins.debian.org is happening right about now, guess it
would help quite something (and I'd be happy to host such tests there).

-- 
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

2015-10-06 Thread Thomas Goirand
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

2015-10-06 Thread Sandro Tosi
(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

2015-10-06 Thread Thomas Goirand
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

2015-10-06 Thread Scott Kitterman
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: mock 1.2 breaking tests (was: python-networkx_1.10-1_amd64.changes ACCEPTED into experimental)

2015-10-06 Thread Jeremy Stanley
On 2015-10-06 09:28:56 +0200 (+0200), Thomas Goirand wrote:
> Master != kilo. It still means that I have to do all of the backport
> work by myself.
[...]
> I know that it's the common assumption that, as the package maintainer
> in Debian, I should volunteer to fix any issue in the 6+ million lines
> of code in OpenStack ! :)
> 
> I do try to fix things when I can. But unfortunately, this doesn't scale
> well enough... In this particular case, it was really too much work.

That is the trade-off you make by choosing to maintain as many
packages as you do. You can obviously either spend time contributing
stable backports upstream or time packaging software. Just accept
that, as with Debian itself, "stable" means OpenStack upstream makes
the bare minimum alterations necessary. This includes, in some
cases, continuing to test the software in those branches with
dependencies which were contemporary to the corresponding releases
rather than chasing ever changing behavior in them. Sometimes it is
done for expediency due to lack of interested volunteer effort, and
sometimes out of necessity because dependencies may simply conflict
in unresolvable ways.
-- 
Jeremy Stanley



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

2015-10-06 Thread Piotr Ożarowski
[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

2015-10-05 Thread Robert Collins
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

2015-10-05 Thread Michael Fladischer
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

2015-10-05 Thread Jeremy Stanley
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

2015-10-05 Thread Scott Kitterman


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

2015-10-05 Thread Barry Warsaw
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

2015-10-05 Thread Barry Warsaw
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

2015-10-05 Thread Barry Warsaw
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

2015-10-05 Thread Mattia Rizzolo
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

2015-10-05 Thread Scott Kitterman
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

2015-10-05 Thread Mattia Rizzolo
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

2015-10-05 Thread Barry Warsaw
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

2015-10-05 Thread Thomas Goirand
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 

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

2015-10-05 Thread Scott Kitterman


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

2015-10-05 Thread Brian May
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

2015-10-05 Thread Scott Kitterman
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 

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

2015-10-05 Thread Thomas Goirand
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

2015-10-05 Thread Thomas Goirand
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

2015-10-05 Thread Scott Kitterman
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 

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

2015-09-30 Thread 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

2015-09-30 Thread 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

2015-09-30 Thread 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

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

2015-09-30 Thread 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

2015-09-30 Thread 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

2015-09-30 Thread 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

2015-09-30 Thread 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

2015-09-30 Thread 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

2015-09-30 Thread 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: 

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

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

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

2015-09-30 Thread 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

2015-09-30 Thread 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

2015-09-30 Thread 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

2015-09-30 Thread 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

2015-09-30 Thread 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

2015-09-30 Thread 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

2015-09-30 Thread 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

2015-09-30 Thread 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.



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

2015-09-29 Thread Scott Kitterman


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

2015-09-29 Thread Barry Warsaw
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

2015-09-29 Thread Piotr Ożarowski
[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

2015-09-29 Thread Sandro Tosi
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



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

2015-09-29 Thread Julien Cristau
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

2015-09-29 Thread Sandro Tosi
> 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

2015-09-29 Thread Julien Puydt
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 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

2015-09-29 Thread Barry Warsaw
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

2015-09-29 Thread Tristan Seligmann
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

2015-09-29 Thread Piotr Ożarowski
[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

2015-09-29 Thread Julien Puydt
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