Greg Stein writes: > <IMO-about-culture> > > API changes probably ought to be discussed on this list (which includes the > maintainers of any code). Basic point: the "maintainer(s)" is usually quite > unclear since we avoid attribution within the source if at all possible. > Posing the suggested change here allows for changing maintainers (note that > Fred has done a tone of work on ConfigParser, and I've submitted a few > changes myself, too!), and it allows for broader input. > > However, bug fixes and minor reworking should probably be allowed regardless > of the maintainer. I'd hate to end up at a point where the Python > interpreter is partitioned into a bunch of little fiefdoms, where you must > pay a toll to enter. > > </IMO-about-culture> Excellent summary. I would add that if a maintainer is actively maintaining their code, it's not polite to check in changes to their code. It's better to give them a chance to fix it first. (The maintainer them should attribute the fix to whoever first mailed it to them, if they use the fix.) --Guido van Rossum (home page: http://dinsdale.python.org/~guido/)
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