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

2015-10-07 Thread Piotr Ożarowski
[Brian May, 2015-10-07]
> > Probably... Now, I've followed your orders not to use Git, General
> > Piotr, so why complaining again?!?
> >
> 
> Unfortunately, terms like "General Piotr" start looking like personal
> attacks; not going to help your arguments.

I take it as a compliment (it's a high rank, after all! ;)

(and even if it doesn't look like it: I like Thomas, all our conversations
in person were nice, even if I approached him due to yet another svn
disaster)...  I guess it's this evil SVN that causing all the troubles!
;)


PS (so that I do not loose my "evil" tag) no, general Piotr says no git
   until migration is done, bite me ;P
-- 
evil Piotr



Re: Python < 3.5 tests

2015-10-07 Thread Robert Collins
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 3, and that code base imports ‘unittest2’, you need
>> > both the Python 2 and Python 3 version of that package.
>> >
>> > If your code base targets only Python 3, it should not be using
>> > ‘unittest2’ at all.
>>
>> Thats false. unittest2 is a rolling backport.
>
> I'm not sure how that disagrees with what I wrote.
>
> Are you saying ‘unittest2’ is useful on Python 3.3 (for example) because
> it has improvements from later Python 3 standard library ‘unittest’?

Yes, exactly. unittest2 is useful and relevant on Python 3.2/3.3/3.4
today. Once we get some fixes into 3.6, it will be useful and relevant
for 3.5 users.

> Or something else?

-Rob


-- 
Robert Collins 
Distinguished Technologist
HP Converged Cloud



Python/LibraryStyleGuide: Executables and library packages dokonana przez BarryWarsaw

2015-10-07 Thread Piotr Ożarowski
[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 the best practices for naming 
> and organizing your binary packages?
> + 
> + Clearly you want to have:
> + 
> +  * python-foo -- the Python 2 library
> +  * python3-foo -- the Python 3 library

 * foo -- for the executable (and possible additional dependencies that 
library doesn't need)

maybe extent it to:

 * python-foo -- the Python 2 library (and Python 2.X scripts if they're 
Python 2.X specific)
 * python3-foo -- the Python 3 library (and Python 3.X scripts if they're 
Python 3.X specific)

> + 
> + but where should the `/usr/bin/foo` script go?  You could put it in 
> `python3-foo` but you '''CANNOT''' put it in `python-foo` or for that matter 
> any binary package that starts with the `python-` prefix.  `dh_python3` 
> refuses to rewrite shebang lines for any executable in a binary package that 
> starts with "python-" or "pypy-".  This means that something like 
> `python-foo-cli` or `python-foo-bin` is unacceptable.

I'd remove this part - it's not dh_python3 specific (dh_python2 and
dh_pypy does similar things) and I don't think such corner case should
be in style guide

> + 
> + Here are some recommendations.  We do not have a standard (though maybe we 
> should):
> + 
> +  * `foo` - this is nice if it parallels the /usr/bin/foo name but it might 
> collide with existing packages, and some people don't like to make such a 
> claim on an unadorned top level package
> +  * `python3-foo-cli` or `python3-foo-bin` - not as nicely discoverable, but 
> `command-not-found` can help, and dh_python3 will work

if someone creates python3-foo-cli binary just to ship /usr/bin/foo it
might as well be foo (if there are no /usr/bin/foo name collisions,
binary package name should be safe as well) so I'd remove it
-- 
Piotr Ożarowski Debian GNU/Linux Developer
www.ozarowski.pl  www.griffith.cc   www.debian.org
GPG Fingerprint: 1D2F A898 58DA AF62 1786 2DF7 AEF6 F1A2 A745 7645


signature.asc
Description: PGP signature


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

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

On Oct 07, 2015, at 11:34 PM, Piotr Ożarowski wrote:

>[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 the best practices for naming 
>> and organizing your binary packages?
>> + 
>> + Clearly you want to have:
>> + 
>> +  * python-foo -- the Python 2 library
>> +  * python3-foo -- the Python 3 library
>
> * foo -- for the executable (and possible additional dependencies that 
> library doesn't need)
>
>maybe extent it to:
>
> * python-foo -- the Python 2 library (and Python 2.X scripts if they're 
> Python 2.X specific)
> * python3-foo -- the Python 3 library (and Python 3.X scripts if they're 
> Python 3.X specific)
>
>> + 
>> + but where should the `/usr/bin/foo` script go?  You could put it in 
>> `python3-foo` but you '''CANNOT''' put it in `python-foo` or for that matter 
>> any binary package that starts with the `python-` prefix.  `dh_python3` 
>> refuses to rewrite shebang lines for any executable in a binary package that 
>> starts with "python-" or "pypy-".  This means that something like 
>> `python-foo-cli` or `python-foo-bin` is unacceptable.
>
>I'd remove this part - it's not dh_python3 specific (dh_python2 and
>dh_pypy does similar things) and I don't think such corner case should
>be in style guide
>
>> + 
>> + Here are some recommendations.  We do not have a standard (though maybe we 
>> should):
>> + 
>> +  * `foo` - this is nice if it parallels the /usr/bin/foo name but it might 
>> collide with existing packages, and some people don't like to make such a 
>> claim on an unadorned top level package
>> +  * `python3-foo-cli` or `python3-foo-bin` - not as nicely discoverable, 
>> but `command-not-found` can help, and dh_python3 will work
>
>if someone creates python3-foo-cli binary just to ship /usr/bin/foo it
>might as well be foo (if there are no /usr/bin/foo name collisions,
>binary package name should be safe as well) so I'd remove it


pgpT040WQ7qgL.pgp
Description: OpenPGP digital signature


Re: Python < 3.5 tests

2015-10-07 Thread Robert Collins
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 /«PKGBUILDDIR»/.pybuild/pythonX.Y_2.7/build;
>python2.7 -m unittest discover -v
>
>--
>Ran 0 tests in 0.000s
>
>OK
>I: pybuild base:170: cd /«PKGBUILDDIR»/.pybuild/pythonX.Y_3.4/build;
>python3.4 -m unittest discover -v
>
>--
>Ran 0 tests in 0.000s
>
>OK
>I: pybuild base:170: cd /«PKGBUILDDIR»/.pybuild/pythonX.Y_3.5/build;
>python3.5 -m unittest discover -v
>ajax_select (unittest.loader._FailedTest) ... ERROR
>
> So it looks like it can't find the tests under Python 2.7 or Python 3.4,
> so it use to work, however under Python 3.5 it now does find the tests
> and they fail.
>
> This left me wondering:
>
> * Why does it not find the tests under Python 2.7, 3.4? What is
>   different about Python 3.5 that it does?
> * Why is Python 3.4 still relevant? Hasn't 3.5 replaced 3.4? Why is it
>   being tested by pybuild?
>
> Regards
>
>


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

2015-10-07 Thread Brian May
On Thu, 8 Oct 2015 at 00:32 Thomas Goirand  wrote:

> You've only enforced *your own* policy, backed-up by only a small vocal
> minority, taking the rule to the extreme (ie: a few days before the Git
> migration, it's still not ok to start new projects using Git, according
> to you...).
>

According to the latest schedule I saw
https://lists.debian.org/debian-python/2015/10/msg00030.html - and as far
as I am aware it is still current, the migration will happen today and
tomorrow (although that probably means a US based timezone, not my UTC+10,
so will be delayed from my perspective).

If this happens, as scheduled, I don't see any point in complaining.

If this isn't happening, maybe your complaint is valid.


I'm sorry, I (honestly) don't remember. Or are you mentioning the fact
> that I had to move my packages that were under Git to another team?
> Probably... Now, I've followed your orders not to use Git, General
> Piotr, so why complaining again?!?
>

Unfortunately, terms like "General Piotr" start looking like personal
attacks; not going to help your arguments.

For the record there are packages in DPMT that are already maintained in
git. Django comes to mind. I think there are others, can't think of the
package names off hand.

The sooner we can move all packages to the agreed git standards, the better.
https://wiki.debian.org/Python/GitPackaging


Re: Python < 3.5 tests

2015-10-07 Thread Robert Collins
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 run unchanged on Python 2
> and Python 3, and that code base imports ‘unittest2’, you need both the
> Python 2 and Python 3 version of that package.
>
> If your code base targets only Python 3, it should not be using
> ‘unittest2’ at all.

Thats false. unittest2 is a rolling backport. A true statement would
be 'if your codebase will only ever run on the latest release of
Python then unittest2 offers no value' for it.

-Rob


-- 
Robert Collins 
Distinguished Technologist
HP Converged Cloud



Python < 3.5 tests

2015-10-07 Thread Brian May
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 tests in 0.000s

   OK
   I: pybuild base:170: cd /«PKGBUILDDIR»/.pybuild/pythonX.Y_3.4/build;
   python3.4 -m unittest discover -v 

   --
   Ran 0 tests in 0.000s

   OK
   I: pybuild base:170: cd /«PKGBUILDDIR»/.pybuild/pythonX.Y_3.5/build;
   python3.5 -m unittest discover -v 
   ajax_select (unittest.loader._FailedTest) ... ERROR

So it looks like it can't find the tests under Python 2.7 or Python 3.4,
so it use to work, however under Python 3.5 it now does find the tests
and they fail.

This left me wondering:

* Why does it not find the tests under Python 2.7, 3.4? What is
  different about Python 3.5 that it does?
* Why is Python 3.4 still relevant? Hasn't 3.5 replaced 3.4? Why is it
  being tested by pybuild?

Regards



Request to join

2015-10-07 Thread Jan-Pascal van Best

-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. Once I noticed it was gone, I've worked
with the previous maintainer and sponsor to get the package back into
shape. It's now in the NEW queue. See the ITP (1). One of the open bugs
for denyhosts mentioned that there was no free software synchronisation
server for denyhosts. See bug#622697 (2). The original author of
denyhosts also operated the sync server, but does not want to open its
source, so in cooperation with the new upstream maintainer I wrote a
AGPL'ed sync server (3). I'm also working on packaging the sync server,
see ITP (4). There is a dependency of the sync server which is not yet
in Debian, an ORM library for the Twisted framework: Twistar (5). There
is also an ITP for it, see (6).

I've read
https://python-modules.alioth.debian.org/python-modules-policy.html and
http://python-apps.alioth.debian.org/policy.html and I accept both.

I've been involved in Debian for around ten years, working first on Java
packages (lucene2, commons-csv). Later on some PHP work
(php-net-nntp,spotweb) and lately Python, as described above.

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
Alioth. Since I  haven't used subversion in years, I've taken the
liberty to use git, gbp and git-dpm as described in Python GitPackaging (7).

Kind regards

Jan-Pascal


 
(1) https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=788994
(2) https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=622697
(3) https://github.com/janpascal/denyhosts_sync
(4) https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=800630
(5) http://findingscience.com/twistar/
(6) https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=800717
(7) https://wiki.debian.org/Python/GitPackaging
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBCAAGBQJWFNl9AAoJEPgwem7WkKwGImgP/j0zpCGPvn8MxU6AxHh5vkSa
xlqJ81MKb9YAeYNYQ1tNy0E8jIFnB4oJ290BzDpk/Qhq1VdWoraP/o8in5yAJ7Fr
hqKPmMu81ima/OY4TyV3MA6m2sCOD330FIMbMH5R8yhPaEX8dGOklddmSCcETe6Z
kJ+K4Hi7IPw2pQSSqstwkl3uS10K+LPzOYDd9hQCVWWCcaNzv5P9oIy/CXz5Au8c
dcSJ4oXVQ4X2P254pJrbiu6JGbxX1MC2uYO7mRInnJSFO9DlChoA0myM4yC3mnWQ
IRyD2v9Jiy990eHJrVd8/jIlKuFWpid91Qpzj7MXa53ILwIB7b3K1A2RiX2lmqd1
3unZxd2vWdvxKTwsvzUExfNRV2fUzsdgedcHuRYtlRyKh2JJf/Scr1VJhA0J85EI
NzXddfP9+G8VFgPUzo3T1gcFy650vhKftujU/NT/8kkvKLopEougX4EknSlx4Iv0
b5sINTOdBsIf3vQfrgFIfG4XXfrF1TB8BmSsK/2ZGqJgdXSsMDX4j7cqQ7ZHN6r/
Qojr6X0BfVKd0js9UGLlT5g5oOzdwWehwEpvPmWWqFAFOyDUH0qzacxAuORsYFH1
qdoFO1fmz4qVnvhs/hoZCXd+8Zvpzo/Bt8T/0cZoFNI9gDN1x2P4Ud/XZMW7BBIc
FJBj6Emc6FqiIbrkYwlP
=ubro
-END PGP SIGNATURE-




Re: Request to join

2015-10-07 Thread Matthias Klose

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

2015-10-07 Thread Arthur de Jong
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 DPMT and PAPT because I think it
improves the overall quality of Debian packages if they are centrally
maintained.

Having centralised infrastructure and policy makes it much easier to
fix things across many packages (e.g. helper package migrations or
updating the (XS-)Vcs-* fields).

I can't say I contribute regularly to other package in either of the
repositories but once in a while I do have time to do QA-like work on a
few packages that are team maintained.

In short, I don't see why I am considered a problem for the team. I'm
not saying I'm a hugely positive addition but removing my packages
because I don't contribute much to other packages will not motivate me
to do more and will probably have the opposite effect for when I do
have some time to spare.

Thanks,

-- 
-- arthur - adej...@debian.org - http://people.debian.org/~adejong --



signature.asc
Description: This is a digitally signed message part


Re: Request to join

2015-10-07 Thread Piotr Ożarowski
[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, I've worked
> with the previous maintainer and sponsor to get the package back into
> shape. It's now in the NEW queue. See the ITP (1). One of the open bugs
> for denyhosts mentioned that there was no free software synchronisation
> server for denyhosts. See bug#622697 (2). The original author of
> denyhosts also operated the sync server, but does not want to open its
> source, so in cooperation with the new upstream maintainer I wrote a
> AGPL'ed sync server (3). I'm also working on packaging the sync server,
> see ITP (4). There is a dependency of the sync server which is not yet
> in Debian, an ORM library for the Twisted framework: Twistar (5). There
> is also an ITP for it, see (6).
> 
> I've read
> https://python-modules.alioth.debian.org/python-modules-policy.html and
> http://python-apps.alioth.debian.org/policy.html and I accept both.
> 
> I've been involved in Debian for around ten years, working first on Java
> packages (lucene2, commons-csv). Later on some PHP work
> (php-net-nntp,spotweb) and lately Python, as described above.
> 
> 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! You read the policy (!), you signed your
mail, you pointed us to your previous work and you have history of
contributions (and DM status, so no worry you will break our machines,
at least not on purpose)

I'd wait 2 or 3 more days in case someone
complains and hit the "add" button immediately...

> Alioth. Since I  haven't used subversion in years, I've taken the
> liberty to use git, gbp and git-dpm as described in Python GitPackaging (7).

but I'll wait till the git transition is over. sorry
-- 
evil Piotr



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

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

You made a point that it was a do-o-cratie earlier, pointing out that
Sandro did so much, and that you did as well, so therefore you had to be
team leader (with the rights to kick anyone?). Therefore, I thought I
had to tell that I do a large chunk of Python packaging work too.

On 10/06/2015 11:36 PM, Piotr Ożarowski wrote:
>> You forced everyone to keep using SVN even after a vote for Git, and
> 
> you mean I enforced our policy which clearly mentions SVN only?

You've only enforced *your own* policy, backed-up by only a small vocal
minority, taking the rule to the extreme (ie: a few days before the Git
migration, it's still not ok to start new projects using Git, according
to you...).

> at the very beginning of your membership didn't you use your own
> workflows in DPMT packages (which you later moved to OpenStack)?

I'm sorry, I (honestly) don't remember. Or are you mentioning the fact
that I had to move my packages that were under Git to another team?
Probably... Now, I've followed your orders not to use Git, General
Piotr, so why complaining again?!?

>> workflow I'm using within PKG OpenStack? Let's say that's what you are
>> referring to, then: I'm the one working on these, and (up to very
>> recently) doing it all alone, so why is this a problem to use the
>> workflow I found the most efficient?
> 
> you can use whatever you want, but if you want a team to work on these as
> well you need to make it easier to contribute to other team members
> (and use what team agreed to use)

I generally agree with *guidelines*. But they should stay guidelines
only, without restricting too much freedom. Sticking with SVN (and even
complaining about the use of git-svn), because of stupid rules
enforcement, for sure, didn't help to make it easy to gather more
contributors.

>> This was for the workflow, it probably also includes tooling.
> 
> yes, especially git-svn was causing pain
> 
>> Would you mind telling what you are referring to?
> 
> I did some work in alembic package, then you decided to move it out from
> DPMT to OpenStack (where I don't have access) and revert some of my work
> (pybuild stuff) because "you don't understand it" without asking me for
> any help.

Ah... Did it strike you that you could (and still can) apply to be a
member of PKG OpenStack? Did you ever thought that I moved it there
because you (and a small minority in this team) was forbidding the use
of git within DPMT?

As for pybuild, maybe it would help if pybuild was better documented
(yes, I am writing this even if I know the /Python/Pybuild wiki
page...). As it stands, for me, it is as much of a gray area as CDBS. It
is fine with very simple packages, but when it becomes more complicated,
I'm a bit lost with it. Probably I should have try harder, and get out
of my comfort zone.

But why are you complaining about all this just now? I don't remember
you ever did before. This leads me to think you do have a problem
talking to me, despite the fact you wrote you don't have anything
personally against me. Otherwise, you would have simply discuss the
mater with me normally, apply to PKG OpenStack, etc. I was in fact
surprised to see you never discuss anything about alembic, and I regret
I didn't attempt to fix the situation.

Last, is not using/liking pybuild a point of argumentation for this
thread? I really don't think it should. You can't and should not impose
pybuild to everyone doing Python packaging. Nor it should be mandatory
to use it within the DPMT.



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

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

2015-10-07 Thread W. Martin Borgert

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 to have the team in "Maintainer" to encourage
others to intervent.

How about leaving it as is? I.e. people in the team decide what is
more appropriate for a package?

Cheers



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

2015-10-07 Thread Arthur de Jong
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 in Uploaders)
- I don't feel primarily responsible for the package but the package
  is useful (team in Maintainer, me in Uploaders)

I think I only added packages in the first category but I also think I
mostly contributed to other packages in the second category.

For most of my packages I'm also upstream and I usually manage so I
would appreciate a heads-up before someone else makes major changes to
my packages.

On the other hand, anything that would make it less work to help other
packages would be positive. Avoiding spending time on trying to get
feedback from people would be good.

I think I'm OK with giving up some authority to my packages in exchange
for lowering the total work required for maintaining all packages. In
general it is probably a net positive for Debian to have less
individual ownership of packages because it creates bottlenecks. I
would welcome having more tools and policy around this.

In that sense, switching to Git can probably help (thanks to everyone
working on that). For example mailing pack...@packages.debian.org with
a pull request would be great.

By the way, still can't promise I'll be able to do much work on other
packages in the near future ;)

-- 
-- arthur - adej...@debian.org - http://people.debian.org/~adejong --



signature.asc
Description: This is a digitally signed message part


linux-sig

2015-10-07 Thread Barry Warsaw
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 this mailing list far and wide.

Cheers,
-Barry


pgpBR8zCUlgw5.pgp
Description: OpenPGP digital signature


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

2015-10-07 Thread Barry Warsaw
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 sense, so where
>would the team appear?
>
>Personally, I prefer to have the team in "Maintainer" to encourage
>others to intervent.
>
>How about leaving it as is? I.e. people in the team decide what is
>more appropriate for a package?

I agree.  I think the recently restated way of interpreting those two fields
made the most sense to me, and gives team members the choice of how to handle
those packages.

* 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 collaboration.  Help in maintaining
  the package is appreciated, commits to vcs are freely welcomed, but before
  uploading, please contact the Maintainer for the green light.

Cheers,
-Barry



Re: team vs individual as maintainer

2015-10-07 Thread Piotr Ożarowski
[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, see attachment
-- 
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
Index: python-modules-policy.rst
===
--- python-modules-policy.rst	(wersja 34513)
+++ python-modules-policy.rst	(kopia robocza)
@@ -54,14 +54,13 @@
 
 This enables the team to have an overview of its packages on the DDPO_website_.
 
-Thus if you bring some packages into the team, you can keep your name in
-the Maintainer field. You will receive bug reports and handle your package
-as usual except that other team members may help from time to time and/or
-take over when you're too busy.
+* 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.
 
-If you put the team in the Maintainer field, the package will be handled
-completely by the team and every member is invited to work on any
-outstanding issue.
+* Team in Uploaders is a weak statement of collaboration. Help in maintaining
+  the package is appreciated, commits to vcs are freely welcomed, but before
+  uploading, please contact the Maintainer for the green light.
 
 Team members who have broad interest should subscribe to the mailing list
 python-modules-t...@lists.alioth.debian.org whereas members who are only


Re: team vs individual as maintainer

2015-10-07 Thread 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 Uploaders is a weak statement of collaboration.  Help in maintaining
>   the package is appreciated, commits to vcs are freely welcomed, but before
>   uploading, please contact the Maintainer for the green light.

how about making it official and adding it to the policy?
-- 
evil Piotr



Re: team vs individual as maintainer

2015-10-07 Thread W. Martin Borgert

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 Uploaders is a weak statement of collaboration.  Help in  
maintaining

  the package is appreciated, commits to vcs are freely welcomed, but before
  uploading, please contact the Maintainer for the green light.


+1


how about making it official and adding it to the policy?


+1



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

2015-10-07 Thread Debian/GNU
-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 the new policy to be, i'm all happy with it.


fgks
IOhannes
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCAAGBQJWFRA4AAoJELZQGcR/ejb4dswP/1/xeEirq5bDspvNRKKZE935
UOu5PSQgpxMVRUJB04FwtwKfFA0eaHSHlIaHO/X7cZ2TVRTQZgxD2hMI4CiSVx04
VDtf7rp7L4DsQtxv8j6ujI60Tu2a3iatedbfSeKdUKOGwakjL8CGG+/QNxGWZzkL
U7VnBOe3lQqDMd9mZoo/La9wguvkFzia72g/QtazORhRuKw5+6h6j2ZFUpac5278
35mbQYrnj4IlSUKinMXj3QNzuLWsVJR4RIpaYLp46DvknDBoW86fDKhfBcl7vFgT
HkZYqAHxw3E1hiyTFBPfkQaUWetk8oBoURVjknH9c/pPMw8ig+ALLvbGjqHlr2a3
AGjSPAJ5/C1UDyyaP2jFtQKYQiUsrQp+xeX2zYvWJc6Z+hg/zKRs/qfFVgNaJS8b
GR/qs4+aFKH2hifFfMga1PKMRgIOpo4kqo245ujnjk9A9Uze8/v46lZOOMTeZmED
v0UInsg52B9/r0qJtle9o518qO+kSQR9ogM42yamG2RUleJhrM7UOjDCvL03JVBl
POpfQGeo2DPJjhLhuDfKHTggjDUZuk18bBUmF539ggOf45zaCnW57DSQDbGAL1N+
Jpse9rxmECI6hR3Wb/zsbu9HrnlrJykagN1Eje5SsPck//lm4gUQKuFZPs+R0IqQ
NHCtEkEmqaOA/AC5FL3i
=d+wY
-END PGP SIGNATURE-



Re: team vs individual as maintainer

2015-10-07 Thread Barry Warsaw
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 required.
>> 
>> * Team in Uploaders is a weak statement of collaboration.  Help in 
>> maintaining
>>   the package is appreciated, commits to vcs are freely welcomed, but before
>>   uploading, please contact the Maintainer for the green light.
>
>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.

Cheers,
-Barry



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

2015-10-07 Thread Nikolaus Rath
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 contact (AKA Maintainer) has to
>   be real person (reason: nobody reads -team mailing list) + automatic
>   team subscription via script that sets up git repository
> * emails with all commits (diffs) made by someone not listed in Maintainer
>   are automatically sent to Maintainer

Sounds good to me.

> * when someone who is not listed in debian/control (i.e.
>   Maintainer/Uploaders) wants to upload team package - just commit
>   and upload to DELAYED/2 (in case of RC bug) or to DELAYED/7, no need
>   to notify anyone, because...

No opinion, I'd need a sponsor anyway.


> * removal¹ of packages (not person) from the team if there's no
>   contribution in 3 months in a row (and given person is not MIA, as in
>   active in other packages, for MIA ones: decide if someone wants to
>   take over or orphan the package, no more team packages that nobody
>   takes care of and no objections if someone takes over your package)
>
> [¹] as in upload to unstable without DPMT in Uploaders, repo stays in
> case one decides come back

Not sure about that one. What would be gained by this? What if the
package is simply in good shape and doesn't need contributions?


Best,
-Nikolaus

-- 
GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F
Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F

 »Time flies like an arrow, fruit flies like a Banana.«



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

2015-10-07 Thread Raphael Hertzog
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 a
pain. When I get interested in a package, I subscribe to the package in
the tracker. At some point, I end up the "maintainer" because the former
maintainer left and here I should put myself in maintainer... that would
mean getting duplicate mails and me having to fix my subscriptions
or add procmail rules to avoid this.

So I don't think that this rule gives us more benefits than annoyances.
If you want to identify someone as in charge, let's define that the first
person in the Uploaders field is that person.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: http://www.freexian.com/services/debian-lts.html
Learn to master Debian: http://debian-handbook.info/get/



Re: linux-sig

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

2015-10-07 Thread Ben Finney
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.
>
> https://mail.python.org/mailman/listinfo/linux-sig
>
> Feel free to spread the announcement of this mailing list far and wide.

Is it already available at GMane? If not, adding it is a matter of
 asking GMane to
subscribe, and then getting a list admin to upload the archive of
earlier posts to the list.

-- 
 \   “Repetition leads to boredom, boredom to horrifying mistakes, |
  `\   horrifying mistakes to God-I-wish-I-was-still-bored, and it |
_o__)  goes downhill from there.” —Will Larson, 2008-11-04 |
Ben Finney