headers
Robert Collins | 6 Nov 2011 20:21

group maintenance of packages?

Hi, over at https://launchpad.net/launchpad-project we've got a group
of nearly 20 developers writing and maintaining the various bits of
python code involved in developing running and scripting Launchpad.
Approximately all of it is open source, and much of that we publish on
PyPI. (Some bits are not Python, so not suitable for PyPI :P).

We've got a bit of a maintenance issue though: we have to maintain the
list of folk that can do releases manually for all of these packages.
At the moment we try to make sure there are at least two folk from the
team listed on every package, and if/when one of them leaves the team
we go around and manually add another person (and remove the person
that left the team if they are no longer interested in maintaining
stuff).

I'm wondering if there is an existing way to reduce that overhead
(e.g. there is an API that would let us script a syncronisation with
our team list from Launchpad), or whether we need to (or it would be
better to) extend PyPI to understand the concept of 'team' or 'group'
and let such a team or group be placed in a role.

Your thoughts desired :)

Cheers,
Rob
Permalink | Reply | 1 comment |
headers
Martin v. Löwis | 6 Nov 2011 22:20
Picon
Gravatar

Re: group maintenance of packages?

> I'm wondering if there is an existing way to reduce that overhead
> (e.g. there is an API that would let us script a syncronisation with
> our team list from Launchpad)

There certainly is an API: the role_form URL is fairly stable, and
we are fairly committed to keep the forms "fixed". So just write
a script that posts to that URL.

That said, we may unintentionally break stuff from time to time,
if that happens, speak up (and we just introduce a new URL for
the new form, or make new fields optional).

To figure out the current roles, use the package_roles RPC.

> or whether we need to (or it would be
> better to) extend PyPI to understand the concept of 'team' or 'group'
> and let such a team or group be placed in a role.

Not sure how common that request is to justify the effort.
If done, I think I'd favor a transitive group membership,
similar to Postgres roles (users and groups live in the
same space, and logging in transitively logs you into all your
groups. A group might have a regular password, if you know
the password, you can change group membership).

Regards,
Martin
Permalink | Reply | 0 comments |
headers
Ralph Bean | 9 Nov 2011 19:20
Picon
Gravatar

http://X.pypi.python.org/

Hello,
  I have just setup http://pypi.rit.edu and would like to begin the process of
  reviewing it and registering it as a X.pypi.python.org mirror.

  I have not yet found any documentation on how to start that process, other
  than emailing this list.

Yours-
 -Ralph
Permalink | Reply | 1 comment |
headers
Martin v. Löwis | 9 Nov 2011 21:35
Picon
Gravatar

http://X.pypi.python.org/

Am 09.11.2011 19:20, schrieb Ralph Bean:
> Hello,
>   I have just setup http://pypi.rit.edu and would like to begin the process of
>   reviewing it and registering it as a X.pypi.python.org mirror.
> 
>   I have not yet found any documentation on how to start that process, other
>   than emailing this list.

Sending it to this list is fine. Please let me know (best in private)
whether this host has a fixed address; I'd rather register that instead
of a CNAME. If we can use a fixed IP address, your server will be
g.pypi.python.org, and shall then respond to that name as well
(otherwise, I'll probably make it e.pypi.python.org). I'll also need an
email contact address for this service. If the system has an IPv6
address, let me know that as well.

I think I like this process of posting new proposed mirrors to
catalog-sig: the community needs to gain trust into the mirror operators
(at least into their ability to operate the service; data integrity
 is provided with cryptographic protection as well). Having the operator
introduce themselves (as you did), sounds about right.

Regards,
Martin
Permalink | Reply | 0 comments |
headers
Ralph Bean | 9 Nov 2011 19:07
Picon
Gravatar

http://pypi.rit.edu

Hello,
  I have just setup http://pypi.rit.edu and would like to begin the process of
  reviewing it and registering it as a X.pypi.python.org mirror.

  I have not yet found any documentation on how to start that process, other
  than emailing this list.

Yours-
 -Ralph
Permalink | Reply | 0 comments |
headers
Martin v. Löwis | 12 Nov 2011 18:53
Picon
Gravatar

New mirror

We now have a new PyPI mirror, g.pypi.python.org. It's located in North
America (RIT, Rochester, NY, USA), so for those of you living on that
continent, it might be the fastest one. Thanks for providing it go to
Ralph Bean.

Regards,
Martin
Permalink | Reply | 2 comments |
headers
Robert Collins | 13 Nov 2011 22:06

trove - LGPL v3 not recognised?

I tried to publish a package with
License :: OSI Approved :: GNU lesser General Public License v3

but its rejected - there is a Library or Lesser category, but no
discrimination between v2 and v3 - as v3 is incompatible with v2, I
figure users will want to know.

Whats the 'right way' of handling this?

-Rob
Permalink | Reply | 13 comments |
headers
Martin v. Löwis | 13 Nov 2011 22:25
Picon
Gravatar

Re: trove - LGPL v3 not recognised?

Am 13.11.2011 22:06, schrieb Robert Collins:
> I tried to publish a package with
> License :: OSI Approved :: GNU lesser General Public License v3
> 
> but its rejected - there is a Library or Lesser category, but no
> discrimination between v2 and v3 - as v3 is incompatible with v2, I
> figure users will want to know.
> 
> Whats the 'right way' of handling this?

You should request a new classifier here; I take your message that
you actually do request

License :: OSI Approved :: GNU lesser General Public License v3

I'll let this request sit for some time for people to object,
and then add this classifier. Remind me if I forget.

Regards,
Martin
Permalink | Reply | 12 comments |
headers
Robert Collins | 13 Nov 2011 22:36

Re: trove - LGPL v3 not recognised?

On Mon, Nov 14, 2011 at 10:25 AM, "Martin v. Löwis" <martin <at> v.loewis.de> wrote:
> Am 13.11.2011 22:06, schrieb Robert Collins:
>> I tried to publish a package with
>> License :: OSI Approved :: GNU lesser General Public License v3
>>
>> but its rejected - there is a Library or Lesser category, but no
>> discrimination between v2 and v3 - as v3 is incompatible with v2, I
>> figure users will want to know.
>>
>> Whats the 'right way' of handling this?
>
> You should request a new classifier here; I take your message that
> you actually do request
>
> License :: OSI Approved :: GNU lesser General Public License v3
>
> I'll let this request sit for some time for people to object,
> and then add this classifier. Remind me if I forget.

That would be great!. Uhm I made a typo - lower case l should be upper:
License :: OSI Approved :: GNU Lesser General Public License v3

Cheers,
Rob
Permalink | Reply | 11 comments |
headers
Toshio Kuratomi | 14 Nov 2011 01:37
Picon
Gravatar

Re: trove - LGPL v3 not recognised?

On Mon, Nov 14, 2011 at 10:36:45AM +1300, Robert Collins wrote:
> On Mon, Nov 14, 2011 at 10:25 AM, "Martin v. Löwis" <martin <at> v.loewis.de> wrote:
> > Am 13.11.2011 22:06, schrieb Robert Collins:
> >> I tried to publish a package with
> >> License :: OSI Approved :: GNU lesser General Public License v3
> >>
> >> but its rejected - there is a Library or Lesser category, but no
> >> discrimination between v2 and v3 - as v3 is incompatible with v2, I
> >> figure users will want to know.
> >>
> >> Whats the 'right way' of handling this?
> >
> > You should request a new classifier here; I take your message that
> > you actually do request
> >
> > License :: OSI Approved :: GNU lesser General Public License v3
> >
> > I'll let this request sit for some time for people to object,
> > and then add this classifier. Remind me if I forget.
> 
> That would be great!. Uhm I made a typo - lower case l should be upper:
> License :: OSI Approved :: GNU Lesser General Public License v3

So actually, the GNU licensing classifiers could do with a bit of a thought.
We definitely could use more than we currently have.  How many and the
wording to use could use a bit of discussion:

The GNU licenses all have clauses similar to the following (This particular
wording is the one used in the GPLv2):
(Continue reading)

Permalink | Reply | 10 comments |

Gmane