Giovanni Bajo writes: > On 05/03/2007 20.30, Phil Thompson wrote:
>> 1. Don't suggest to people that, in order to get their patch >> reviewed, they should review other patches. The level of knowledge >> required to put together a patch is much less than that required >> to know if a patch is the right one. > +1000. Been there, done that. If the submitter doesn't have a pretty good idea that a patch is "the right one", he's making substantial demands on core developer time. "+1000" suggests you think that core developers are using their time with ruinously low efficiency. I think the "review some patches" test is exactly the right one. The requirement is not that you channel the BFDL, it's that you read the patch and bring your own knowledge of the problem to bear. This has three benefits: (1) the reviewed patches get some comments; (2) the reviewed patches come to the attention of a committer; (3) the reviewer comes to the attention of a core developer, and can be considered for commit privileges, etc. An informal version of this process is how XEmacs identifies its Reviewers (the title we give to those privileged to authorize commits to all parts of XEmacs). People who care enough to make technical comments on *others'* patches are rare, and we grab the competent ones pretty quickly. >> 2. Publically identify the core developers and their areas of >> expertise and responsibility (ie. which parts of the source tree >> they "own"). The XEmacs experience has been that the core developers are "ministers without portfolio". You can't wait around for the "owner", who may be on Mars, and you rarely need to. > I think this should be pushed to its extreme consequences for the > standard library. Patching the standard library requires *much > less* knowledge than patching the standard core. Basically, almost > any Python developer in the wild can quickly learn a module and > start patching it in a few days/weeks -- still, the stdlib is a > total mess of outdated and broken modules. The mess is not "total", as Josiah Carlson points out. To the extent that it is a mess, it is the consequence of a process similar to the one you propose to institutionalize. > My suggestion is: > > - keep a public list of official maintainers for each and every > package/module in the standard library (if any, otherwise > explicitly specify that it's unmaintained). This is what XEmacs does; it works, but it's not as effective as you might hope. What happens for us is that many modules are maintained by an interest group disjoint from the core. By giving a representative of the interest group commit privileges, things get addressed pretty quickly and competently. However, this is a convenience for users of the module more than a way of kickstarting a development process (note that the interest group already exists). This requires a separate distribution of the standard library. Two points: recall the ElementTree thread. There were other plausible candidates. The XEmacs policy in such case is that they are all considered equally, and all are allowed to be distributed with the package distribution. In Python, this would conflict with TOOWTDI. Second, where the stdlib module is closely bound to the core, the maintainer ends up being the group of core developers. It can't be any other way, it seems to me. > - if there's no maintainer for a module, the *first* volunteer > can become so. I doubt this will work. It is usually the case that the first volunteer is acceptable, but it shouldn't be policy. > - *any* patch to stdlib which follows the proper guidelines (have > a test, don't break compatibility, etc.) *must* be applied *unless* > the maintainer objects in X days (if a maintainer > exists... otherwise it will just go in). This is an obviously bad idea. The stdlib needs to be deliberately pruned, not arbitrarily patched. _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
