Tarek Ziadé schrieb:
On Fri, Oct 31, 2008 at 7:46 AM, Nick Coghlan [EMAIL PROTECTED] 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.
___
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