[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