Re: managing transitions

[Mattia Rizzolo]

On Tue, Oct 06, 2015 at 04:03:54PM +0200, Thomas Goirand wrote:
> On 10/06/2015 01:02 PM, Mattia Rizzolo wrote:
> > 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).
> 
> I don't think a single machine is enough for this kind of workload.
> Imagine the upload of a new setuptools and rebuilding all packages
> build-depending on it. That's a lot of packages to rebuild in
> jenkins.d.o. I have offers from some cloud providers which we could use
> instead for this kind of job. We "only" need to do the work...

jenkins.d.o won't build anything but only keep the master node (without
builders, or maybe one or two to do maintenance stuff).

If what you would like to do is to "just" rebuild all rdeps, that's
really one of the thing I'd really like to do, it just takes time do all
the work (and atm I'm busy doing other stuff, if that wasn't clear) :)

To be precise, what I plan is to really improve the current
reproducible.d.n scripts and base everything on them.
I'd like to support both rebuilds on a modified toolchain on demand and
on all r-deps of a particular packages which uploads would act as a
trigger.
It just takes a shitload of time I don't currently have, as usual.
Currently there are means to ask for rebuild of stuff using a particular
packages (through the AWS credit, managed by lucas &
I-don't-remember-who), but to me it looks like it's not really used if
not for big packages (like, before gcc uploads), and the results are
somewhat difficult to access and understand and often used by a single
person, which sucks.

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

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

[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: managing transitions

[Ian Cordasco]

On Tue, Oct 6, 2015 at 1:11 PM, Barry Warsaw  wrote:
> On Oct 06, 2015, at 07:05 PM, Thomas Goirand wrote:
>
>>Interesting. It's the first time I hear about it, I thought it was just
>>closed source.
>
> The instance at gitlab.com is the non-free Enterprise Edition (EE).  EE has
> features we probably don't care about ayway.  The Community Edition (CE) is
> MIT/Expat.
>
>>Does it have test capabilities as well, so that we could
>>run tests on each new patch, like Gerrit does? Can we plug zuul and
>>nodepool to it?
>
> I don't know about plugging in zuul and nodepool, but the CE does have CI
> integration, which we use in the GNU Mailman project, and seems to work
> great.

It definitely can integrate with its own CI (which I believe is also
licensed similarly to GitLab CE) as well as Jenkins. Currently the
Flake8 project is hosted and developed on GitLab and uses integration
with vanilla Jenkins.

Re: managing transitions

[Barry Warsaw]

On Oct 06, 2015, at 07:05 PM, Thomas Goirand wrote:

>Interesting. It's the first time I hear about it, I thought it was just
>closed source.

The instance at gitlab.com is the non-free Enterprise Edition (EE).  EE has
features we probably don't care about ayway.  The Community Edition (CE) is
MIT/Expat.

>Does it have test capabilities as well, so that we could
>run tests on each new patch, like Gerrit does? Can we plug zuul and
>nodepool to it?

I don't know about plugging in zuul and nodepool, but the CE does have CI
integration, which we use in the GNU Mailman project, and seems to work
great.

Cheers,
-Barry

Re: managing transitions

[Barry Warsaw]

On Oct 06, 2015, at 03:12 PM, Fred Drake wrote:

>What CI tools are you using with GitLab CE?

We don't run CE; we use the hosted EE at gitlab.com.  But anyway, we have a
custom VM on which we run the GitLab runner software in a docker image.  This
runs our test suite in all supported Python 3s against both SQLite and
PostgreSQL.  At the time we set things up they didn't have shared runners, but
now they do so I don't think you even need to provision a VM.

http://doc.gitlab.com/ci/

Cheers,
-Barry


pgp1V5NfV0r9R.pgp
Description: OpenPGP digital signature

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

[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

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

[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: Git migration schedule

[Debian/GNU]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 2015-10-05 23:24, Barry Warsaw wrote:
> On Oct 05, 2015, at 10:36 PM, Stefano Rivera wrote:
> 
>> How about: We move away existing repositories, and put the 
>> migrated ones in the /packages/ path. If people have existing 
>> repositories, that they'd prefer to use, they can move the 
>> migrated ones out the way, and theirs back. But they have to opt 
>> in to this.

sounds good.
in my case, i have (to admit that i have) 3(!) git repos for which
there is no svn repo at all.
so there won't be any clash during migration, and moving them away
would not be strictly necessary.
for the sake of simplicity, i guess that they probably should be moved
away in any case.

>> This means some (work done on pre-migration git packaging) 
>> history gets temporarily "lost".

the cue point here is "temporarily".

> But ensures that everything is the same layout. And
>> that any deviation was intentional, not accidental.
> 
> I think it would be okay.  It's only a minor inconvenience, 
> although the git remotes of the packages that get moved would also 
> be temporarily incorrect.

+1

i don't know how long you expect the migration to run; but even though
there are *many* repopsitories to migrate i don't think that it will
last longer than...2 days?



fgmasdr
IOhannes

PS: have i told you already how excited i am that this is finally
happening! big thanks for all the preparation work ♥
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCAAGBQJWE3iwAAoJELZQGcR/ejb431sP/27eSQpArjlAk27zGlXDZiMy
4mF4LnYgBXMOORnReSnTRqIksr3CC9ZImM3XUbDEcloQaGqFZln18MZeMRFlquKK
7KS95nfSP49D8+aPhSlAfPuSMcFdMg0Nu0FX534HCJ/qXPLT67dZA+H1BH3kEGmg
knNaV5etaUCXU4QaiAThZMTUbzs30nqduMBqU5FtqJhubPwTEJ0COplDenglRtHx
DJSQSgC3KPiwy/ehOdR4kttojGQ7yjXiPIa8rRS9RmSGdYOwA5QPx+eQNnDwD1w+
vSMKAuUlKKPFysABus0VVMdhP+U88J7PieWH299HfiWnuxwWrYQnXD5O6pfb5+oE
++WhVMq2s/jNT4CqnyCQCaLW3EM5vrK7pl7TujynC3IsZxzeHXkZMfojsOjMCfYP
Sfn/lTak1cYFgGU6+LFhaHzWIFWULE/TiE1zQePGbAcMGkLqGSmbT/H/ma3fFGnG
ghiVqrX5FYvi3BkUUeDtLHYgsS1oGR3hHYrA6rEVl/4jxg4LT03DI7nSK0yQFyJW
JgKVvTYrzdoFyzCASoEVuwN9i5kKN72QxfeZa/q3WP5E3+ZcWGcyadQsnwDke0gh
Q1p5lSeKv3vaNMvQFyJmSSb1cCcMGpb5MViFJ41rdGEQdNz2ZRgvkQsXDmnl859q
cLVzk4YvL1annB/4UdlD
=/CdQ
-END PGP SIGNATURE-

Re: How to convert a git repo to git-dpm

[Julien Puydt]

Hi,

Le 05/10/2015 20:27, Julien Puydt a écrit :

(3) git-dpm init ../foo_version.orig.tar.gz (start using git-dpm)


That point takes actually longer, because one needs to have the tarball 
around ; this is now wishlist bug #801086 against git-dpm

( https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=801086 )


(4) for each patch, use "git-dpm apply-patch"


This just means:
git-dpm apply-patch /path/to/first_patch
git-dpm apply-patch /path/to/second_patch
...

git-dpm will turn each patch into a nice commit (provided those are good 
DEP3 patchs -- a good Description: and a good Author: )



I hope that helps,

Snark on #debian-python

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

[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

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

[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

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

[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

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

[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

[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

[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

[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

[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: managing transitions

[Thomas Goirand]

On 10/06/2015 01:02 PM, Mattia Rizzolo wrote:
> 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).

I don't think a single machine is enough for this kind of workload.
Imagine the upload of a new setuptools and rebuilding all packages
build-depending on it. That's a lot of packages to rebuild in
jenkins.d.o. I have offers from some cloud providers which we could use
instead for this kind of job. We "only" need to do the work...

Cheers,

Thomas

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

[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

[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: managing transitions

[Thomas Goirand]

On 10/06/2015 05:42 PM, Barry Warsaw wrote:
> 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.

Interesting. It's the first time I hear about it, I thought it was just
closed source. Does it have test capabilities as well, so that we could
run tests on each new patch, like Gerrit does? Can we plug zuul and
nodepool to it?

FYI, I have Zuul and Nodepool nearly done. I am just waiting for the
support of statsd 3.x to land upstream (as it'd be broken in Sid otherwise).

Cheers,

Thomas Goirand (zigo)

Re: mock 1.2 breaking tests

[Thomas Goirand]

On 10/06/2015 05:26 PM, Ian Cordasco wrote:
> 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).

Yes. I agree, and I am very well aware of these facts. I was barely
pointing it out, thanks for writing it better than I ever would.

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

:)