Tarek Ziadé schrieb:
On Fri, Oct 31, 2008 at 7:46 AM, Nick Coghlan
wrote: What about having two level of devs ?
+ core developers + standard library developers
[cut]
So I'd suggest thinking about developer responsibilities more in terms of areas of expertise rather than "levels" of developers. Those of us that happen to understand the guts of the compiler or the VM aren't more competent globally or more trusted than those maintaining the various modules in the standard library - just interested in different things.
Right,
I would like to share my experience about this, if it can be helpful.
I have focused so far in distutils, which, I believe was not in the top priority of core developers during the last year. (If this is not true please forgive me).
I think it's safe to say that anything not directly involved in Python 3000 changes was not top priority for most core developers.
Anyway, so I am starting to become quite specialized in this part of Python, and I pushed patches for it in the tracker.
The patches I wrote that made it so far took between 4 to 8 months to be applied.
I have really simple patches for distutils that are just adding tests, that are waiting for review. I guess these patches will be reviewed in a few months, I am failry confident about that. I know core developers are drowned into more important topics. And this area of Python is being highly discussed to be refactored, maybe outside the stdlib at some point, but there are a *lot* of simple things to do today in there.
So basically, if I want to be efficient in distutils I need to become a core developer, and this means (Guido said) I need to start providing patches for the rest of the Python code and eventually (after a few years I guess) maybe become a core developer.
I don't think this is what Guido meant. Or, put differently, it depends on what being a "core developer" means. If it isn't the same as "committer", maybe. However, there is nothing wrong with being a committer and an expert on part of the code.
Then I'll be able to work in distutils because at that point in the future I'll be trusted.
I can't do that ! I don't have the time to become a Python core code expert. But in my everyday work I became a packaging / deploying specialist.
So my point is : if I am "trusted" at some point in the work I am doing in distutils, will I have a commit access there ?
If I'm not mistaken, nobody will object to that. In the beginning you should find another developer who reviews your (pending) checkins, so that code style and other conventions are maintained. The most important thing for distutils is of course backwards compatibility, so that nobody is forced to rewrite their setup.py scripts. Especially for distutils, there is the SIG mailing list which is meant as the authoritative group for distutils decisions. (I'm not subscribed to it, so perhaps you've already discussed your intended changes there.) cheers, Georg -- Thus spake the Lord: Thou shalt indent with four spaces. No more, no less. Four shall be the number of spaces thou shalt indent, and the number of thy indenting shall be four. Eight shalt thou not indent, nor either indent thou two, excepting that thou then proceed to four. Tabs are right out.