On 4/26/06, Gerhard Häring <[EMAIL PROTECTED]> wrote:
> Brett Cannon wrote:
> > OK, I am going to write the PEP I proposed a week or so ago, listing
> > all modules and packages within the stdlib that are maintained
> > externally so we have a central place to go for contact info or where
> > to re
Michael Hudson wrote:
> Gerhard Häring <[EMAIL PROTECTED]> writes:
>
>> Currently I'm not subscribed to python-checkins and didn't see a need
>> to. Is there a need to for Python core developers?
>
> I would say it's "encouraged".
>
>> I think there's no better way except subscribing and defin
Gerhard Häring <[EMAIL PROTECTED]> writes:
> Currently I'm not subscribed to python-checkins and didn't see a need
> to. Is there a need to for Python core developers?
I would say it's "encouraged".
> I think there's no better way except subscribing and defining a
> filter for SQLite-related c
Brett Cannon wrote:
> OK, I am going to write the PEP I proposed a week or so ago, listing
> all modules and packages within the stdlib that are maintained
> externally so we have a central place to go for contact info or where
> to report bugs on issues. This should only apply to modules that wan
Fredrik> applying emergency patches (stuff that blocks the build, and
Fredrik> security fixes) is of course okay, but I would prefer if
Fredrik> everything else is handled via the ET master repository.
Could that reference be placed in a comment near the top of
xmlcore/etree/ElementTr
Brett Cannon wrote:
> > Not sure whether Fredrik Lundh has responded, but I believe he once
> > said that he would prefer if ElementTree isn't directly modified, but
> > that instead patches are filed on the SF tracker and assigned to him.
>
> Nope, Fredrik never responded. I am cc:ing him direct
On 4/16/06, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> Brett Cannon wrote:
> > Basically, from all the replies I have gotten has said that package
> > that were/are externally maintained either considers Python HEAD as
> > the current version or watches checkins and the bug tracker and thus
> >
Brett Cannon wrote:
> Basically, from all the replies I have gotten has said that package
> that were/are externally maintained either considers Python HEAD as
> the current version or watches checkins and the bug tracker and thus
> the PEP is really not needed. So unless some package steps forwar
On 4/8/06, Brett Cannon <[EMAIL PROTECTED]> wrote:
> OK, I am going to write the PEP I proposed a week or so ago, listing
> all modules and packages within the stdlib that are maintained
> externally so we have a central place to go for contact info or where
> to report bugs on issues. This should
On Sat, Apr 08, 2006 at 02:47:28PM -0700, Brett Cannon wrote:
> OK, I am going to write the PEP I proposed a week or so ago, listing
> all modules and packages within the stdlib that are maintained
> externally so we have a central place to go for contact info or where
> to report bugs on issues.
On 4/10/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
>
> Brett Cannon wrote:
> > OK, I am going to write the PEP I proposed a week or so ago, listing
> > all modules and packages within the stdlib that are maintained
> > externally so we have a central place to go for contact info or where
> >
Brett Cannon wrote:
> OK, I am going to write the PEP I proposed a week or so ago, listing
> all modules and packages within the stdlib that are maintained
> externally so we have a central place to go for contact info or where
> to report bugs on issues.
Based on the recent interchange regardin
Brett Cannon wrote:
> OK, I am going to write the PEP I proposed a week or so ago, listing
> all modules and packages within the stdlib that are maintained
> externally so we have a central place to go for contact info or where
> to report bugs on issues. This should only apply to modules that wan
At 09:35 AM 4/10/2006 +1000, Andrew Bennetts wrote:
>On Sun, Apr 09, 2006 at 02:48:47PM -0400, Phillip J. Eby wrote:
> > At 07:56 PM 4/9/2006 +0200, Martin v. Löwis wrote:
>[...]
> > >-1. These aren't external libraries; they are part of Python.
> >
> > They *were* external libraries. Also, many O
On Monday 10 April 2006 04:48, Phillip J. Eby wrote:
> They *were* external libraries. Also, many OS vendors nonetheless
> split the standard library into different system packages, e.g.
> Debian's longstanding tradition of excising the distutils into a
> separate python-dev package.
Ubuntu (a de
On Sun, Apr 09, 2006 at 02:48:47PM -0400, Phillip J. Eby wrote:
> At 07:56 PM 4/9/2006 +0200, Martin v. Löwis wrote:
[...]
> >-1. These aren't external libraries; they are part of Python.
>
> They *were* external libraries. Also, many OS vendors nonetheless split
> the standard library into diff
Phillip J. Eby wrote:
> I was hoping that we had reached a point where setup.py could simply
> become the One Obvious Way to do it, in which case the One Obvious Way
> to bundle formerly-external libraries would be to bundle their setup
> scripts.
Well, setup.py cannot (yet?) replace the other mec
At 07:56 PM 4/9/2006 +0200, Martin v. Löwis wrote:
>Phillip J. Eby wrote:
> > It would be good if we could have separate setup.py files for "external"
> > libraries, not only because of the ability to get PKG-INFO installed, but
> > also because then OS vendors that split those externals out into s
Phillip J. Eby wrote:
> It would be good if we could have separate setup.py files for "external"
> libraries, not only because of the ability to get PKG-INFO installed, but
> also because then OS vendors that split those externals out into separate
> system packages wouldn't need to jump through
At 02:47 PM 4/8/2006 -0700, Brett Cannon wrote:
> Do people think we need to document the version that has
>been imported into Python and when that was done as well?
Definitely. Better yet, in 2.5 I'd like to have the version information
embedded in a PKG-INFO file that gets installed with Pyth
On 4/8/06, Brett Cannon <[EMAIL PROTECTED]> wrote:
> Anyway, here is a list of the packages that I think have outside
> maintenance (or at least have been at some point). Anyone who has
> info on them that I need, please let me know the details. Also, if I
> missed any, obviously speak up:
I thi
On 4/9/06, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> Brett Cannon wrote:
> > - expat
>
> Not sure whether you mean the Expat parser proper here, or the pyexpat
> module: both are externally maintained,
I was thinking the parser, but if pyexpat is externally maintained,
then both of them.
> a
Brett Cannon wrote:
> - expat
Not sure whether you mean the Expat parser proper here, or the pyexpat
module: both are externally maintained, also; pyexpat is part of PyXML.
OTOH, people can just consider PyXML to be part of Python, and I
synchronize the Python sources with the PyXML sources from t
"Brett Cannon" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> This should only apply to modules that want
> bugs reported outside of the Python tracker and have a separate dev
> track. People who just use the Python repository as their mainline
> version can just be left out.
If
On Sat, 2006-04-08 at 14:47 -0700, Brett Cannon wrote:
> - email
This has an standalone release, but development and bug reports should
all happen in the Python project.
-Barry
signature.asc
Description: This is a digitally signed message part
___
P
OK, I am going to write the PEP I proposed a week or so ago, listing
all modules and packages within the stdlib that are maintained
externally so we have a central place to go for contact info or where
to report bugs on issues. This should only apply to modules that want
bugs reported outside of t
26 matches
Mail list logo
