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

[Brian May, 2015-10-07] > > Probably... Now, I've followed your orders not to use Git, General > > Piotr, so why complaining again?!? > > > > Unfortunately, terms like "General Piotr" start looking like personal > attacks; not going to help your arguments. I take it as a compliment (it's a high

Re: Python < 3.5 tests

On 8 October 2015 at 12:05, Ben Finney wrote: > Robert Collins writes: > >> On 8 October 2015 at 11:47, Ben Finney wrote: >> > If you have a code base that is intended to run unchanged on Python >> > 2 and Python

Python/LibraryStyleGuide: Executables and library packages dokonana przez BarryWarsaw

[Debian Wiki, 2015-10-07] > https://wiki.debian.org/Python/LibraryStyleGuide?action=diff=64=65 > > > == Gotchas == > > + === Executables and library packages === > + > + Let's say you have a Python package which results in Python 2 and 3 > libraries, and a Python 3 executable. What is

Re: Python/LibraryStyleGuide: Executables and library packages dokonana przez BarryWarsaw

Thanks for the feedback. I did rewrite this a little bit, so hopefully it's clearer. I left some of the text in there because at least to me it reads better and provides some rationale for why the rules are there. But hey, it's a wiki so please feel free to make further improvements! Cheers,

Re: Python < 3.5 tests

Probably the discover improvements in 3.5 try using python -m unittest2.discover On 8 Oct 2015 10:12, "Brian May" wrote: > Hello, > > When debugging #801208, I noticed the following output: > >dh_auto_test -O--buildsystem=pybuild >I: pybuild base:170: cd

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

On Thu, 8 Oct 2015 at 00:32 Thomas Goirand wrote: > You've only enforced *your own* policy, backed-up by only a small vocal > minority, taking the rule to the extreme (ie: a few days before the Git > migration, it's still not ok to start new projects using Git, according > to

Re: Python < 3.5 tests

On 8 October 2015 at 11:47, Ben Finney wrote: > Brian May writes: > >> I see that there is a python3-unittest2 package - should I be using that >> one or the unittest built in Python 3.5? > > If you have a code base that is intended to

Python < 3.5 tests

Hello, When debugging #801208, I noticed the following output: dh_auto_test -O--buildsystem=pybuild I: pybuild base:170: cd /«PKGBUILDDIR»/.pybuild/pythonX.Y_2.7/build; python2.7 -m unittest discover -v -- Ran 0

Request to join

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi Debian-Python folks, I'd like to join the Debian Python application and modules teams. I'm a DM and my Alioth account is janpascal-guest. The root cause for this request is the dropping of the denyhosts package (a Python package) from Jessie.

Re: Request to join

On 07.10.2015 11:46, Piotr Ożarowski wrote: [Jan-Pascal van Best, 2015-10-07] I look forwarded to working with you on Python packaging. If I'm accepted into the team, I'll upload the packaging work up to now to oh, best join request so far! do you call him by name or value? ;)

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

On Fri, 2015-10-02 at 09:12 -0700, Nikolaus Rath wrote: > 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. Same here. I have a few packages in

Re: Request to join

[Jan-Pascal van Best, 2015-10-07] > I'd like to join the Debian Python application and modules teams. I'm a > DM and my Alioth account is janpascal-guest. > > The root cause for this request is the dropping of the denyhosts package > (a Python package) from Jessie. Once I noticed it was gone,

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

On 10/06/2015 11:36 PM, Piotr Ożarowski wrote: > my point is that you could argue that your packages are better > maintained than ours (less bug reports, wider Python 3 support, > newest upstream releases, more popcon users, ...) but you choose the > fact that you maintain more of them... and then

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

I no longer think requiring contribution (the 3 months thing) is a good idea for DPMT (might be for a new team). I assume you all like other ideas, like no team in Maintainer, right? -- evil Piotr

team vs individual as maintainer (was: radical changes)

Quoting Piotr Ożarowski : I assume you all like other ideas, like no team in Maintainer, right? To me, "team maintenance" would mean, that the team appears in the "Maintainer" field. In "Uploaders" it doesn't make sense, so where would the team appear? Personally, I prefer

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

On Wed, 2015-10-07 at 14:18 +0200, Piotr Ożarowski wrote: > I assume you all like other ideas, like no team in Maintainer, right? I kind of liked the differentiation between the two options: - I'm the primary maintainer and welcome other people working on my    packages (me in Maintainer, team

linux-sig

In the upstream Python project, we recently created a new mailing list as a focal point for cross-distro Linux-specific issues. I invite all interested folks to join and help make Python better on Linux. https://mail.python.org/mailman/listinfo/linux-sig Feel free to spread the announcement of

Re: team vs individual as maintainer (was: radical changes)

On Oct 07, 2015, at 02:33 PM, W. Martin Borgert wrote: >Quoting Piotr Ożarowski : >> I assume you all like other ideas, like no team in Maintainer, right? > >To me, "team maintenance" would mean, that the team appears in the >"Maintainer" field. In "Uploaders" it doesn't make

Re: team vs individual as maintainer

[Barry Warsaw, 2015-10-07] > >how about making it official and adding it to the policy? > > I thought you had volunteered to do that (with native speaker review)? I > previously mistakenly remembered Scott volunteering for that. > > If not, I'm happy to do it. I meant to use your exact words,

Re: team vs individual as maintainer

[Barry Warsaw, 2015-10-07] > * Team in Maintainers is a strong statement that fully collaborative > maintenance is preferred. Anyone can commit to the vcs and upload as > needed. A courtesy email to Uploaders can be nice but not required. > > * Team in Uploaders is a weak statement of

Re: team vs individual as maintainer

Quoting Piotr Ożarowski : [Barry Warsaw, 2015-10-07] * Team in Maintainers is a strong statement that fully collaborative maintenance is preferred. Anyone can commit to the vcs and upload as needed. A courtesy email to Uploaders can be nice but not required. * Team in

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

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 2015-10-07 14:18, Piotr Ożarowski wrote: > I no longer think requiring contribution (the 3 months thing) is a > good idea for DPMT (might be for a new team). > > I assume you all like other ideas, like no team in Maintainer, > right? if that's

Re: team vs individual as maintainer

On Oct 07, 2015, at 03:29 PM, Piotr Ożarowski wrote: >[Barry Warsaw, 2015-10-07] >> * Team in Maintainers is a strong statement that fully collaborative >> maintenance is preferred. Anyone can commit to the vcs and upload as >> needed. A courtesy email to Uploaders can be nice but not

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

On Oct 07 2015, Piotr Ożarowski wrote: > I no longer think requiring contribution (the 3 months thing) is a good > idea for DPMT (might be for a new team). > > I assume you all like other ideas, like no team in Maintainer, right? > > * team only in Uploaders field, the main

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

On Wed, 07 Oct 2015, Piotr Ożarowski wrote: > I assume you all like other ideas, like no team in Maintainer, right? While I understand the desire to have one identified maintainer for each package, I don't agree with the rule. Changing maintainer means changing the flow of information and it is

Re: linux-sig

On Oct 08, 2015, at 05:34 AM, Ben Finney wrote: >Is it already available at GMane? It's been requested and acknowledged, and I resent a message to kick off creation of the newsgroup, but I don't see it there yet and the gmane.org website seems offline for me atm. Cheers, -Barry

Re: linux-sig

Barry Warsaw writes: > In the upstream Python project, we recently created a new mailing list as a > focal point for cross-distro Linux-specific issues. I invite all interested > folks to join and help make Python better on Linux. > >