[Python-Dev] External Package Maintenance

Phillip J. Eby pje at telecommunity.com
Tue Jun 13 02:22:46 CEST 2006


At 01:49 AM 6/13/2006 +0200, Martin v. Löwis wrote:
>Phillip J. Eby wrote:
> > This should definitely be explained to authors who are donating
> > libraries to the stdlib, because from my perspective it seemed to me
> > that I was graciously volunteering to be responsible for *all* the work
> > related to wsgiref.
>
>It's not only about python-wide changes. It is also for regular error
>corrections: whenever I commit a bug fix that somebody contributed, I
>now have to understand the code, and the bug, and the fix.

Again, my point was that I was volunteering to do all of those things for 
wsgiref.


>Under PEP 360, I have to do all of these, *plus* checking PEP 360 to determine
>whether I will step on somebodies' toes. I also have to consult PEP 291,
>of course, to find out whether the code has additional compatibility
>requirements.

In the wsgiref case, you mustn't forget PEP 333 either, actually.  :)


>So ideally, I would like to see the external maintainers state "we can
>deal with occasional breakage arising from somebody forgetting the
>procedures". This would scale, as it would put the responsibility
>for the code on the shoulders of the maintainer. It appears that Thomas
>Heller says this would work for him, and it worked for bsddb and
>PyXML.

I've also already said I can use Barry's approach, making the Python SVN 
repository version the primary home of wsgiref and taking snapshots to make 
releases from.  I didn't realize that cross-directory linkages of that sort 
were allowed, or I'd have done it that way in the first place.  Certainly 
it would've been a more effective use of my time to do so.  :)



More information about the Python-Dev mailing list