On Wed, 4 Oct 2017 11:52:32 +0200 Victor Stinner <victor.stin...@gmail.com> wrote: > > It's also hard to find open bugs of a specific module on > bugs.python.org, since almost all bugs are in the very generic > "Library" category. Using full text returns "false positives". > > I would prefer to see more specific categories like: > > * Buildbots: only issues specific to buildbots > * Networking: socket, asyncio, asyncore, asynchat modules > * Security: ssl module but also vulnerabilities in any other part of > CPython -- we already added a Security category in NEWS/blurb > * Parallelim: multiprocessing and concurrent.futures modules
This is mixing different taxonomies and will make things ambiguous. If there's a crash in socket.sendmsg() that affects mainly multiprocessing, should it be in "Networking", "Security" or "Parallelism"? If there's a bug where SSLSocket.recvinto() doesn't accept some writable buffers, is it "Networking" or "Security"? etc. I agree with making the "Library" section finer-grained, but then shouldn't the subsection be simply the top-level module/package name? (e.g. "collections", "xml", "logging", "asyncio", "concurrent"...) Also, perhaps the "blurb" tool can suggest a category depending on which stdlib files were modified, though there must be an easy way for the committer to override that choice. > I don't think that we need a distinct categoy for each module. We can > put many uncommon modules in a generic category. What is the problem with having a distinct category for each module? At worse, the logic which generates Docs from blurb files can merge some categories together if desired. There's no problem with having a very fine-grained categorization *on disk*, since the presentation can be made different. OTOH if the categorization is coarse-grained on disk (such is the case currently), the presentation layer can't recreate the information that was lost when committing. Regards Antoine. _______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com