Martin v. Löwis wrote: >> +lots on adding a module field (independent of automatically adding >> maintainers to the nosy list, it would assist in "I just did a major >> cleanup of module X, are there any old bugs I can kill off"). > > Link (1:1) or Multilink (1:n)? What is the impact on the Component field? I was thinking multilink, and leaving component alone - the module field would largely come into play when the component was just the "Lib" catch-all. > Would you be willing to manage the field (in the sense of managing the > set of values)? If so, please send me a list of values. I would suggest just using the module index from the documentation to seed any such list of modules in the tracker: http://docs.python.org/modindex.html Packages could generally be left as a single entry in the list. The only exception I think is that there should be an "xml.etree" entry separate from the main "xml" entry, and perhaps a separate entry for "os.path". Deprecated modules could either be left out of the list, or else moved to appear at the end. Regards, Nick. -- Nick Coghlan | ncoghlan at gmail.com | Brisbane, Australia ---------------------------------------------------------------
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4