[Python-Dev] Encouraging developers

Neal Norwitz nnorwitz at gmail.com
Wed Mar 7 07:33:10 CET 2007


On 3/6/07, Terry Reedy <tjreedy at udel.edu> wrote:
>
> ""Martin v. Löwis"" <martin at v.loewis.de> wrote in message
> news:45ED3506.9040707 at v.loewis.de...
> >1. Public identification will not help, because:
> >2. most code isn't in the responsibility of anybody (so publically
> >    identifying responsibilities would leave most code unassigned), and
> >3. for the code that has some responsible member, things are already
> >    fine (so public identification won't improve here)
>
> If I were looking for an 'ophan' (python-coded) module to adopt,
> then such a list would help me choose.

  os.listdir(os.path.dirname(os.__file__))

Does that help? :-)

It's not really that far off, though.  :-(

Larger modules that have been contributed recently like subprocess and
tarfile are well maintained.  Most other modules are less so.  Most of
the modules don't have problems.  However, many of the web-centric
modules have outstanding issues, as does sre.  I think some of the
shell utility modules (shutil, path handling) have issues wrt
portability.

There are also many problems that only occur on one platform (most
often Windows, AIX, or HP-UX).  I won't touch these sorts of problems
unless I can properly verify the problem and the fix.  Generally
problems in these areas don't have tests which make fixing them
without access to the platform too costly IMO.

asyncore has a lot of outstanding issues IIRC.  Also many issues are
documentation.

I think it would be best for people to pick a module they are
interested in and knowledgeable about.  We could create a wiki that
would be for informational use.  If it works well, maybe we could
formalize it.  Start something, announce it to python-list or
python-dev, and try it.  If it works, we'll adopt it.

> It would also be helpful if the new tracker system could produce a list of
> module-specific open items sorted by module, since that would indicate
> modules needing attention, and I could look for a batch that were
> unassigned.

Agreed.  That's why I wanted keywords to be supported (which I believe
they are).  If we can slice and dice the issues up into categories, it
will be easy to figure out where we need to spend more time.  It also
can be a great incentive to drop 5 issues to 0.  Going from 977 to
972, just isn't as satisfying.

n


More information about the Python-Dev mailing list