Re: Git migration schedule

[Daniel Stender]

Hi,

these old SVN repos could be spared and removed:

On 03.10.2015 20:52, Stefano Rivera wrote:
> The errors:
> 
> Cannot "git-dpm init" package: gamera

is already in: git://anonscm.debian.org/python-modules/packages/gamera.git

> Cannot "git-dpm init" package: nltk

old/obsolete packaging, the initial Debian package was uploaded for Debian 
Science

> Cannot "git-dpm init" package: svg.path

got into: 
http://anonscm.debian.org/cgit/python-modules/packages/python-svg.path.git
before the initial upload

and

> Cannot "git-dpm init" package: pyuca

... is currently in NEW. I'll convert that manually.

Cheers,
DS

-- 
4096R/DF5182C8
46CB 1CA8 9EA3 B743 7676 1DB9 15E0 9AF4 DF51 82C8
LPI certified Linux admin (LPI000329859 64mz6f7kt4)
http://www.danielstender.com/blog/

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

[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

How to convert a git repo to git-dpm

[Julien Puydt]

Hi,

I would like to open a nice thread to discuss the "problem" of packages 
already managed in git, but not with git-dpm.


To start the discussion, I'll describe how I did things and what I did 
to "convert" a repository.


My usual way to use a repository is doing things like:
gbp import-orig (when a new version comes out)
gbp buildpackage -S [-us -uc | -kdebian] to get a source package
and use quilt to manage my (rare) patches.

Here is what I came up with for the transition:
(1) copied patches elsewhere (/tmp/somewhere/, say)
(2) git rm -r debian/patches && git commit -m "Remove old patch management"
(3) git-dpm init ../foo_version.orig.tar.gz (start using git-dpm)
(4) for each patch, use "git-dpm apply-patch"
(5) git-dpm update-patches
after that, git-dpm status seems happy.

I hope this helps,

Snark on #debian-python

Bug#801058: ITP: nbconvert -- Jupyter notebook conversion

[Julien Puydt]

Package: wnpp
Severity: wishlist
X-Debbugs-CC: debian-python@lists.debian.org

* Package name: nbconvert
  Version : 4.0.0
  Upstream Author : Jupyter Development Team
* URL : https://github.com/jupyter/nbconvert
* License : BSD-3-clause
  Programming Lang: Python
  Description : Jupyter notebook conversion
 Jupyter nbconvert converts notebooks to various other formats
 using Jinja templates.

Cheers,

Snark on #debian-python

Re: Git migration schedule

[Stefano Rivera]

Hi Barry (2015.10.05_17:51:41_+0200)
> >and other 9, for a grand total of 109 packages that cannot be
> >converted to git, 13.5% of DPMT (oh, what about PAPT?)
> 
> I've wondered about PAPT too.  I don't touch those nearly as often, but
> eventually yes, they should come under the same vcs regime, IMHO.

One step at a time. The same scripts should work, with minimal tweaks :)

SR

-- 
Stefano Rivera
  http://tumbleweed.org.za/
  +1 415 683 3272

Re: Git migration schedule

[Stefano Rivera]

Hi IOhannes (2015.10.05_12:07:33_+0200)
> >> sorry, i forgot to ask another question: how will the packages
> >> already maintained in git be handled?
> > 
> > Up to their maintainers (assuming they're following team
> > standards). If people only have one git package, for testing, each,
> > then this shouldn't be an issue :)
> 
> what does this mean in practice?
> what if people have more than one git package, not only for "testing"
> purposes?

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.

This means some (work done on pre-migration git packaging) history gets
temporarily "lost". But ensures that everything is the same layout. And
that any deviation was intentional, not accidental.

SR

-- 
Stefano Rivera
  http://tumbleweed.org.za/
  +1 415 683 3272

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

[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

Bug#800936: ITP: ipykernl -- IPython kernel for Jupyter

[Julien Puydt]

Package: wnpp
Severity: wishlist
X-Debbugs-CC: debian-python@lists.debian.org

* Package name: ipykernel
  Version : 4.0.3
  Upstream Author : Jupyter Development Team
* URL : https://github.com/ipython/ipykernel
* License : BSD-3-clause
  Programming Lang: Python
  Description : IPython kernel for Jupyter
 This software component provides an IPython kernel, which will hook
 itself into Jupyter.

Cheers,

Snark on #debian-python

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

[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

[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

[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

[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

[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: [DPMT] radical changes: automation, carrot and stick

[Barry Warsaw]

On Sunday, October 04, 2015 11:54:18 PM Stefano Rivera wrote:

>There's a fundamental question to ask here. Do we want to welcome Python
>packages into the team, or do we want to put up barriers and require a
>level of commitment before packages can be brought into the team?

Thanks Stefano for stating this in such a clear way.  It is indeed a (*the*?)
fundamental question to ask about this team.

On Oct 05, 2015, at 07:23 AM, Scott Kitterman wrote:

>I think that you describe to reasonably accurate directions the team can go.  
>Personally, I prefer the "natural home for most Python packages in the 
>archive" vision.
>
>I think we should have a minimum of rules, but people should follow the ones 
>we do have.

+1 and +1

Cheers,
-Barry

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

[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

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

[Barry Warsaw]

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.
>
>This means some (work done on pre-migration git packaging) history gets
>temporarily "lost". 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.

Cheers,
-Barry

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

[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

[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

[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

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

[Brian May]

On Tue, 6 Oct 2015 at 02:49 Barry Warsaw  wrote:

> Waiting longer isn't an option IMHO.  It's helping to add to the
> dysfunction
> of the team.  I will also offer to help if the 3.5 transition gets stuck
> because of the git conversion.
>

Hurry up and break my packages :-)

Do the Vcs-* headers in debian/control get updated automatically or do
these need to be updated manually? Looks like it gets updated
automatically. Good.

Maybe after the migration, add a check to lintian to check for obsolete
Vcs-*? Might ensure no accidents happen, e.g. with somebody building and
uploading from old subversion by mistake.

Thinking it might be good to have a list somewhere of packages that should
get manually checked (and where this hasn't happened yet) after the
migration is complete. Otherwise we might all assume somebody else has
checked a package, and it gets forgotten.

I guess I should look at my packages. They tend to be relatively simple,
don't expect any problems.

Just one problem(?) I do see, some of the commits corresponding to patches
have the following committer:

Stefano Rivera 

e.g.

https://anonscm.debian.org/cgit/python-modules/svn-migration/django-tables.git/commit/?id=17afaee37dc0be9d40ba5bdd1af8f254ef42a46a

from:

https://anonscm.debian.org/cgit/python-modules/svn-migration/django-tables.git/

This looks like a mistake to me, Stefano didn't contribute these changes.
Suspect it might be a default used because there was no author information
in the original debian/patches/* file.

Re: Git migration schedule

[Barry Warsaw]

On Oct 05, 2015, at 10:32 PM, Stefano Rivera wrote:

>Hi Barry (2015.10.05_17:51:41_+0200)
>> >and other 9, for a grand total of 109 packages that cannot be
>> >converted to git, 13.5% of DPMT (oh, what about PAPT?)
>> 
>> I've wondered about PAPT too.  I don't touch those nearly as often, but
>> eventually yes, they should come under the same vcs regime, IMHO.
>
>One step at a time. The same scripts should work, with minimal tweaks :)

Oh for sure!  There's no deadline on "eventually" :)

Cheers,
-Barry

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

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

[Barry Warsaw]

On Oct 05, 2015, at 07:12 PM, Barry Warsaw wrote:

>I did an update (not uploaded) of webob from this migration and it worked
>perfectly.  But it's a simple package without patches.  I'll try a few more.

Similarly for ply 3.8.  The nice thing here is that there were several quilt
patches that got applied upstream and were no longer necessary.  git-dpm
recognized this and automatically deleted those patches.

For both packages `git-dpm tag` DTRT.

Cheers,
-Barry


pgpBmeBJPea0z.pgp
Description: OpenPGP digital signature

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

[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

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

[Barry Warsaw]

On Oct 03, 2015, at 08:52 PM, Stefano Rivera wrote:

>So, here is a migration at r34461:
>https://anonscm.debian.org/cgit/python-modules/svn-migration/

I did an update (not uploaded) of webob from this migration and it worked
perfectly.  But it's a simple package without patches.  I'll try a few more.

Cheers,
-Barry


pgpY7b4eQYxMv.pgp
Description: OpenPGP digital signature

Re: Git migration schedule

[Debian/GNU]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 2015-10-04 23:06, Stefano Rivera wrote:
> Hi Sandro (2015.10.04_21:31:07_+0200)
>> sorry, i forgot to ask another question: how will the packages
>> already maintained in git be handled?
> 
> Up to their maintainers (assuming they're following team
> standards). If people only have one git package, for testing, each,
> then this shouldn't be an issue :)

what does this mean in practice?
what if people have more than one git package, not only for "testing"
purposes?

fgmd
IOhannes


-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCAAGBQJWEkviAAoJELZQGcR/ejb4zdkP/2o10WRkf8ErOTloLo2myUb4
BoL3KX2xLKTQ4TZZfXlXKdRig2T9lLLIHZGsDDHmqRO9lrsCe8AbNQBLYvBtgCtI
VkJ/83CGGS8d3qiVGs5neeHl281aWyO4fDImyntHDxqRAa3zaIbZ3PeH6hvt3Mu/
Wk3KGBZuQ66yFBDMjBMATbhFDB0H/03wDA5f3pU7RJuAwdn9PjZfmSgJ4giHZ8cS
HhIIhxy+Kka8VkmpUT6xMx/LFEIviUHUi9y2IqMpgzGFcXNH/xRIVEWA5pRcrHzS
On5kM+sPwFwaAoy0A/OWyxzOcsPmdQV3lkbvYixH4FeWDX6kqpzynryCABh3eQ31
6MScD4SXtu0zpjlz7FvFhYB/cAkXJduWBwgfnHp4ikZopTlHEKD6gVV2rDBVUgXn
Ne5zlJfOBXEED4RWO4pWRM79qRjofjIjbNcSKHyDe5612C2wKBrUyFnYDTMahRbE
8+BbQJANKYhPGmX92TGO3gTHEMsDwGZ4sJmFuCGFwA4xfGtniPae+ciseUR/dPIC
uBlEmlAwVzKn0cXpJSSEuhxcQ5fvjWPG5dkFrj4NduMJ5VB2bH6aDuLqs4OgMKs4
wdLOTXtxvELBZ98hHlMsVsipeeALyl8ZxygNv57OXlbcwvk1AyGkgBiiGZHYqnQ2
BvSu38QmpsCRz7YWO+N8
=83EB
-END PGP SIGNATURE-

Re: [DPMT] radical changes: automation, carrot and stick

[Debian/GNU]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 2015-10-02 10:30, Piotr Ożarowski wrote:
> it's 3 months to contribute to other packages (the ones where
> you're not listed in Maintainer).

hmm.
if i - hypthotically, because i really currently do not - cared a so
much about e.g. 30 DPMT packages¹ that i have added myself to the
Uploaders and which have active upstreams and thus require a fair
amount of regular maintainance work, then i would need to do to
*another* contribution each month in order to not get kicked out of
the team?

sounds a bit like penalizing the wrong ones to me.


fgamsdr
IOhannes

¹ just made up numbers; assuming only a single real person is in
"Uploaders/Maintainers"; and that the 16 team members listed in
https://wiki.debian.org/Teams/PythonModulesTeam are the only really
active ones; and that all other 300 members only injected a single
package into the current 779 ones; gives the active members about 30
packages each on average.
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCAAGBQJWElJMAAoJELZQGcR/ejb4vwsP/0xbLTgajbmg7AyJzeStWulR
5ggQQx1L853ER69sqR9Kfmv9+cBo2ijl39m+libY8o20QUyglM4+/QKNYA2mto5X
izcPA+ZD0RFePA5z9yCHZNBUQnLpNX9C8+N0qAWAdeVO7fYUbkr3plBvaP+CvdLc
Fv8OQ0t5dNYnmnMV3T6BYmCxqJMido0FM78n8xhE+A1XSs+saBjA3JlXyyNxy7MC
V3K0/SYtV0db4rhboTrrGRaDv6ZQMIlL+czEWfDgwBqnWVtK3AdZSLZdJRF9JeN8
CWjv4CjEADeI2vtt38dYvj8GVlm5G6b528bP/ABrbCVPm4DO18zjpnIxILFPnGcg
0C07nWtcnceRW2mcR/tFERTTtWfa8l77cpf4VknKb9dCKfiHn9buB1YLFfWKi9wm
l8ZvyTg74apMpX583bdOvlAkzVp+nGv7TYUxxdntKj2/H/Phwz1cbb68vQ5onhNP
B7JZMlJPao3PrEqKnv6ftBR8AO1/WD6aEeJRlBBHQjONCSeQZuERMv8CWWSoUt2J
Zy0Ak4TuGvzsuik6nQhszVV48G/h9vlWJPeHhfddJPrQPLhA+u9zKqLumB2QipoD
5lb5BcPEUzszvi3Lw56vSTkMTqJ88GE+zC2GeILFP5aS+uRJ9Yihcd0D1ZzXoLoV
MjEfLMt/EDZmmzQTO22p
=6kim
-END PGP SIGNATURE-

Re: [DPMT] radical changes: automation, carrot and stick

[Scott Kitterman]

On Sunday, October 04, 2015 11:54:18 PM Stefano Rivera wrote:
> This thread has had me thinking a bit.
> 
> Hi Scott (2015.10.02_20:34:16_+0200)
> 
> > Personally, I like the current approach where someone can either commit to
> > either strong team maintainership (DPMT in maintainer) or weak team
> > involvement (DPMT as uploader).  If you'll check, I have done both and it
> > reflects my level of interest in the package.
> 
> I like it too, but I don't actually use it very accurately. Whether I'm
> maintainer or uploader for a package is more an accident of history than
> anything else. I should probably fix that.
> 
> That said I haven't found it makes much difference to people's
> contributions to my packages. I've woken up to find that something was
> added to SVN and uploaded, immediately.
> 
> > Personally, I would find this kind of rule demotivating.  I think it will
> > actually discourage participation which isn't what we want.
> 
> There's a fundamental question to ask here. Do we want to welcome Python
> packages into the team, or do we want to put up barriers and require a
> level of commitment before packages can be brought into the team?
> 
> What are the possible outcomes of either choice?
> 
> 
> I'd imagine that if we're open, we become the natural home for most
> Python packages in the archive.
> Transitions become easier, and standardisation of the vast majority of
> Python packages in the archive is within our power.
> 
> We'll collect cruft. But so does the rest of the archive. I don't think
> being open will necessarily increase the amount of crufty Python in the
> archive.
> 
> 
> On the other hand, if we raise barriers, we reduce the size and
> influence of the team. The few packages we maintain, we can probably
> maintain to a higher standard. Maybe there'd be less bickering, because
> we'd be working together more (not that I think we have much).
> Newcomers would be rarer (there's a commitment) but more valuable to the
> team. Or would we start to attract people faster because of our level of
> activity?
> 
> Of the newcomers we turn away, I don't think most will abandon their pet
> packages. They'll just not do it in our team. New Python teams will form,
> and many more Python packages will be individually maintained. I know
> most of us have QA interests wider than the team, and this isn't
> desirable for us.
> 
> How would we feel if a cabal-free-python team formed? Would any of us
> join it?
> 
> And as to cruft. What happens when a widely-used package that is
> maintained by a 3-month inactive maintainer gets evicted? Do we orphan
> it? Alternatively, is the team prepared to take on all these packages?
> 
> 
> If we want to seriously think about these issues, should we start
> lighter-weight?
> 
> * Audit the team for crufty packages that should be RMed.
> * or need love.
> * Audit the team for inactive members.
> * ... and their packages.
> 
> Doing something about these is within our power right now.
> 
> Can we find "carrot" ways to encourage team members to work on packages
> besides their own?
> 
> Many of the problems arising from inactive team members are problems
> that affect the wider Debian, equally.

I think that you describe to reasonably accurate directions the team can go.  
Personally, I prefer the "natural home for most Python packages in the 
archive" vision.

I think we should have a minimum of rules, but people should follow the ones 
we do have.

Scott K

Re: [DPMT] radical changes: automation, carrot and stick

[Debian/GNU]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 2015-10-02 18:12, Nikolaus Rath wrote:
> On Oct 02 2015, Piotr Ożarowski  wrote:
>> I think that the main problem of our team is that we have over
>> 300 members and only few people contribute to packages they
>> didn't inject to the repo (some people do not care even about
>> those).
> 
> I always assumed that it was generally preferred to have Python
> packages be maintained in the Python team, even if the maintainer
> has little interest or time in contributing to other Python
> packages.
> 
> Did I get the wrong impression?

this was also my impression and the main reason why i joined the team.

i brought in 3 packages needed as a dependency for some other package
maintained by pkg-multimedia; the 3 modules are general purpose, so it
makes little sense to maintain them in pkg-multimedia - DPMT seemed to
be the right place.

as others have mentioned, i also set DPMT as "maintainer", in order to
not keep anybody from contributing (and not because I wanted to unload
the packaging burden on the team).

fgmasdr
IOhannes

-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCAAGBQJWEkhCAAoJELZQGcR/ejb41YgP/3n5Ji/EUuzUhHI3+MRHMa6I
etTAP3KJkKtKipKOdgnmUDn4XLLM+aM4M3V2Y1O/FOu+R/dJc/+ynnGZS47twLJm
edjFNSRhjiLDGTk4Io0m7jgV80YCr+5MfCe2/dnrIE4mEM4z69Cjo6cR+G2adz8f
EhoScamtuhkyJ26fH3OMgBTWJLMwP1zUilhySSCxvRf8U7mSBHH2ugNdu7ph7t1N
EL4e2ySvV0JNA2Pd6PQG/6vL8/EvMpzLXBBeLAAAm63kT2UhLryb5yTABFIxyz3d
odn+hVFHhJuoTRxYiH6apTr/RxX1za7lYAY7aXcsIt1h/jL3uy6L4vm3XtJReAaR
6FWqVjoJdHzn/NUID3bgHTv4L2csolKI+TPcnvpzR0VYMOtcNfIVhkKEthTP0ybC
D7iPKtqtK/idM34Oc7cZnF0Abk4LWr9kakgt816mNsm4/GI9e1ipqwyQNx/21eF0
cBVfjX1+xQohRP+7Lw58+RTVHPUp05Z5ld8qD0XrNwMWjF3HiASo65HVUVVy0cph
lYwPgG8mk46a+Bsxy4Kjvi4LAY33MeUphbsGfgqMA11eUF9zHtbPIBetxh1+Ip46
geU06DiPsX4CE70WLnAZoQQujANG/haSI1/ULF19pouC7L7sLN711PuQ4WvEh5M6
foeUUpjt2NzuFvR2KCbF
=n8eR
-END PGP SIGNATURE-

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

[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

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

[Barry Warsaw]

On Oct 04, 2015, at 08:03 PM, Sandro Tosi wrote:

>am I the only one thinking it's quite a huge number to be handled by
>hand? and whose hands will be the ones converting these packages?
>yours or Barry's dont seem enough and others will need training/time.

I'm happy to pitch in if a maintainer needs help doing so.  I'd like to at
least capture the manual steps needed on the GitPackaging page.  I'm not sure
if there is enough commonality to make that worthwhile, but there might be.

>Additionally, now we are in the middle of the 3.5 transition, and so
>packages will need updating rather quickly: are we sure this is the
>best time to push full throttle with the migration? I'd rather wait a
>little bit longer and have a more automatic migration at a calmer
>moment for python modules.

Waiting longer isn't an option IMHO.  It's helping to add to the dysfunction
of the team.  I will also offer to help if the 3.5 transition gets stuck
because of the git conversion.

Cheers,
-Barry

Re: Git migration schedule

[Barry Warsaw]

On Oct 04, 2015, at 08:31 PM, Sandro Tosi wrote:

>sorry, i forgot to ask another question: how will the packages already
>maintained in git be handled?

It should be easy.  Just push it to the team's vcs.  If it's not already in
git-dpm it's pretty easy to bootstrap.  Essentially just one call to git-dpm
init with the latest pristine tar.  It's possible that it will leave you with
limited pristine tar history, but most of the time YAGNI.

You might also have to futz with branch names to use the official names, and I
wouldn't worry if your older tag formats didn't match.

And we do have an "out" although I would caution to use it *very* sparingly
and only with a really good reason.  If your package *has to* diverge from
team standards, you must add a debian/README.source explaining why, and how to
interact with vcs for your package.  It should be needed only rarely.

Cheers,
-Barry

Re: Git migration schedule

[Scott Kitterman]

On Monday, October 05, 2015 11:49:01 AM Barry Warsaw wrote:
> On Oct 04, 2015, at 08:03 PM, Sandro Tosi wrote:
> >am I the only one thinking it's quite a huge number to be handled by
> >hand? and whose hands will be the ones converting these packages?
> >yours or Barry's dont seem enough and others will need training/time.
> 
> I'm happy to pitch in if a maintainer needs help doing so.  I'd like to at
> least capture the manual steps needed on the GitPackaging page.  I'm not
> sure if there is enough commonality to make that worthwhile, but there
> might be.
> >Additionally, now we are in the middle of the 3.5 transition, and so
> >packages will need updating rather quickly: are we sure this is the
> >best time to push full throttle with the migration? I'd rather wait a
> >little bit longer and have a more automatic migration at a calmer
> >moment for python modules.
> 
> Waiting longer isn't an option IMHO.  It's helping to add to the dysfunction
> of the team.  I will also offer to help if the 3.5 transition gets stuck
> because of the git conversion.

The first phase of the transition is almost done (92% or so), so I don't think 
that it's a valid reason to hold things up.  In fact, from a transition 
perspective, ~now is good so it can all be settled out before we want to make 
python3.5 default.

Scott K

Re: Git migration schedule

[Barry Warsaw]

On Oct 03, 2015, at 08:52 PM, Stefano Rivera wrote:

>No significant failures, but I wanted to setup an mr config, which I've done
>now:
>https://anonscm.debian.org/cgit/python-modules/svn-migration/python-modules.git/
>The pkg-perl team has fancier tools, but they require more bookkeeping, so I
>mostly cribbed from the pkg-ruby-extras team.

Is there some documentation on how to use these scripts, or set up mr?  Or
would that be obvious for anybody who's used mr before?

Can you add something about mr to https://wiki.debian.org/Python/GitPackaging
?

Cheers,
-Barry

Re: Git migration schedule

[Barry Warsaw]

On Oct 03, 2015, at 08:52 PM, Stefano Rivera wrote:

>So, here is a migration at r34461:
>https://anonscm.debian.org/cgit/python-modules/svn-migration/
>
>The errors:

Some of these may already be in git, and hopefully git-dpm so don't actually
need a conversion.  If it's in git but not git-dpm, it's fairly easy to
bootstrap, though perhaps with less history, but fully functional going
forward.

I've not done a full review of this list, but the ones I know about are (sorry
Piotr ;):

>Cannot "git-dpm init" package: pycurl
>Cannot "git-dpm init" package: python-pip

Cheers,
-Barry

Re: Git migration schedule

[Barry Warsaw]

On Oct 04, 2015, at 08:03 PM, Sandro Tosi wrote:

>and other 9, for a grand total of 109 packages that cannot be
>converted to git, 13.5% of DPMT (oh, what about PAPT?)

I've wondered about PAPT too.  I don't touch those nearly as often, but
eventually yes, they should come under the same vcs regime, IMHO.

Cheers,
-Barry