[Python-Dev] My patches

[Georg Brandl]

Tarek Ziadé schrieb:
> On Fri, Oct 31, 2008 at 7:46 AM, Nick Coghlan <ncoghlan at gmail.com> 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.